Developers of Sympa

[IKEDA Soji <address@concealed>]

All,

It is hot.  Tokyo in the last week was hotter than Cairo, Kolkata,
Bangkok, ...and so on!  So I fear my response might be a bit garbled.

On Mon, 19 Aug 2013 15:26:51 +0200
Guillaume Rousse <address@concealed> wrote:

> Le 07/08/2013 18:08, IKEDA Soji a écrit :
> >>> - fatal_err() vs. croak().
> >>>
> >>>     fatal_err() seems to be replaced by croak() in most cases.
> >>>     Former requires Sympa module, while latter needs just a standard
> >>>     Carp module.
> >>>
> >>>     What are pros to use fatal_err()?
> >> It just predates usage of exceptions, and should better be dropped in
> >> favor a exception handler in top-level code.
> >
> > You proposed it before.  I have carefully thought on it for
> > a while, and personally concluded that it would not be adopted.
> >
> > Perl5 does not have true exception handling such as
> > "try-except-finally-else" structure and "raise" statement (e.g. in
> > Python).  Behaviors of eval() and die() [or croak()] sometimes look
> > similar, however, they may be rather a Perl version of setjmp(3) and
> > longjmp(3).
> >
> > To express exception handling by Perl5, code will be forced to be
> > slightly complex.  Though some CPAN modules have been proposed to
> > ease it, they often fail to implement perfect syntax for exception
> > handling.
> >
> > So my conclusion is: We should not try to emulate exception handling
> > on Perl5, although I deeply feel how better Perl5 had supported it.
> First, you're confusing catching and analysing exceptions here. Second, 
> even string-based exceptions, such as raised by die() or croak() already 
> allow minimal analysis. We really don't care if that's a "false" or 
> "true" model, as long as it works sufficiently for our needs.
> 
> fatal_error("foobar") logs "foobar", send a notification to listmaster, 
> then call exit. It doesn't have any understanding of what exact the 
> problem is, it just ensure proper recording of the event before exiting. 
> You can achieve exactly the same result by wrapping the main infinite 
> loop of all daemons:
> 
> eval {
>      while (1) {
>         # do some stuff here...
>      }
> };
> if ($EVAL_ERROR) {
>      log("something wrong happened: $EVAL_ERROR");
>      notify("something wrong happened: $EVAL_ERROR");
>      exit(1);
> }
> 
> Code using fatal_error("foobar") hardcodes the logic "foobar message 
> goes to syslog then to sendmail command, then everything stops". Code 
> using croak("foobar") instead is much more flexible, as the error flow 
> can be handled differently according to the context. When recovery is 
> possible, for instance, there is no reason to quit. In unit testing 
> scenario, you also need to re-route the error message without having to 
> dig in actual syslog content. Etc...

I thought of "true" exception handling.  I espacially would like to
emphasize use of "finally" clause which cannot be realized by simple
"eval-die" implementation.  For example on discussion about lost
connection on database, I suppose your proposal might not be perfect
in short.

> Morevoer, you were the first one to implement such an exception handler 
> in Sympa::Site, so I really don't understand this sudden change of mind...

It just indicates bug in sources: If program dies, it indicates that
non-existing parameter was referred.

When this is replaced by Site->get_parameter() or similar thing,
if a non-existing parameter name was given, it should die, instead of
ordinary protocol to return undef, I suppose.  Because undef can be
proper value of parameter.

In my conclusion, "eval-die" protocol may be usable in limited cases.
but not general exception cases.


Regards,

-- Soji


-- 
株式会社 コンバージョン  セキュリティ&OSSソリューション部   池田荘児
〒231-0004　神奈川県横浜市中区元浜町3-21-2 ヘリオス関内ビル7F
e-mail address@concealed  TEL 045-640-3550
http://www.conversion.co.jp/