Markus Peter wrote:
>
> Glenn Linderman wrote:
> >
> > For example, if truly fatal errors could be distinguished, one
> > could declare that a catch-all clause "catch { ... }" would not
> > catch fatal errors, that it would be necessary to specifically
> > list that you want to catch a fatal error... maybe "catch Fatal
> > { ... }", or the like.
>
> Yes, we'll probably need an easy way to distinguish truely,
> absolutely fatal stuff (out of memory or some other sort of
> runtime error by the interpreter) from ordinary exceptions.
This form is documented as proposed in RFC 88:
catch $@->{severity} eq "Fatal" => { ... }
and I'm adding this to the next version, as a convenience method:
catch $@->fatal => { ... }
> I'm not sure though wether I like the usage of die to throw fatal
> exceptions vs. throw for possibly non-fatal exceptions, especially
> considering the fact that many modules currently use die for
> trivial stuff like reporting wrong parameters...
Agreed. Please don't do that. Down that path lies ruin.
> A better way would probably be to use different base classes, like
> Exception for an exception which might be a problem but not very
> serious and Error for the real, usually always fatal problems.
I don't think that's a good idea. Fatality is a property, not
a part of your name. But if you want to, RFC 88 supports this
form already:
catch Exception::Fatal => { ... }
That's making an awful mess of the class hierarchy though.
Yours, &c, Tony Olekshy
