Re: On the case for exception-based error handling.

[Peter Scott]

At 12:41 PM 8/23/00 -0700, Glenn Linderman wrote:
> > > But on the other hand, if you really want to trap both fatal and
> > > non-fatal errors, doing it via a single general exception
> > > mechanism is nice.  How can we achieve both?
> >
> > RFC 88 already achieves both, like this:
> >
> >         catch $@->{severity} eq "Fatal" => { ... }
>
>... we find that at least some errors have preclassified themselves as
>fatal!

'fatal' is in the eye of the beholder.  Perl already lets you trap fatal 
errors; look at the exceptions labelled '(F)' in perldiag which you can 
trap with an eval.  What one layer considers fatal may be merely a glitch 
to a higher layer.  Heck, there's an impedance mismatch between perl5db.pl 
and CGI::Carp on this very point: see what happens when you debug a program 
that does use CGI::Carp qw(fatalsToBrowser): the latter traps a 'fatal' 
error thrown by the former when it's merely trying to find a Term::ReadLine 
by going through a list of possibilities.

Anyone can call any error they like 'fatal', but there will always be users 
of that code who want to reserve the right to apply a different 
interpretation, which is what Tony was talking about above.
--
Peter Scott
Pacific Systems Design Technologies