Glenn Linderman wrote:
>
> Tony Olekshy wrote:
>
> > > Glenn Linderman wrote:
> > >
> > > I'm now reaching the conclusion that RFC 88 is apparently
> > > building more mechanism around item 2 to make it prettier for
> > > use as a general exception mechanism. If so, I don't think
> > > that is a good idea.
> >
> > In some ways you are oversimplifying the problem, and in other
> > ways it's less complex than you think. The main things to keep
> > in mind are that exceptions and errors aren't the same thing,
> > that exceptions are just one way of signalling errors, and that
> > exceptions can be used for signalling things other than errors
> > (such as success).
You are oversimplifying by mixing the notions of exceptions and
errors, whether you are aware of their difference or not. You are
overcomplicating because you have two mechanisms, one for fatal and
one for non-fatal, when in fact they are the same.
> I'm also aware that fatal and non-fatal errors aren't the same
> thing.
But, they are, except one has its fatal bit set.
> > Remember, it's up the catcher to determine whether or not an
> > exception should be considered an error, and if so, whether or
> > not it should be fatal. If the the thrower already knew that,
> > in many cases they wouldn't have to throw at all.
>
> This is a nice motherhood statement, but later you contradict it...
>
> > > 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!
Right, but that didn't predermine how they were handled, it was up
to the catcher to check the classification.
> > RFC 88 doesn't change the way die or eval work, so why would you
> > want to automatically convert them to throw and catch?
>
> RFC 88 doesn't change the way die or eval work, unless you turn it
> on. But if you want to use RFC 88 features, then you have to turn
> it on, and then die becomes throw.
Nope. die is still die. throw is die too, in fact, RFC 88 literally
defines throw in terms of die. RFC 88 doesn't change how die works.
It only changes what $@ is (while preserving stringification for
"traditional" use), nothing else.
> By making throw/catch an orthogonal facility, whether it is turned
> on or off, any traditional Perl code that misuses die/eval for
> non-fatal errors will continue to work exactly as it currently
> does. I don't think RFC 119 suffers from such a problem.
There is no way in which so-called "fatal" error handling is
orthogonal to so-called "non-fatal" error handling, for any value of
orthogonal. If they were orthogonal, their dot product would be 0.
As it is, their (normalized) dot product is essentially 1. They
aren't at right angles; their co-angle is essentially 0.
RFC 88 suffers from no traditional die/eval problem because turning
it on doesn't affect their behaviour at all.
The fact that turning on RFC 119 breaks traditional die/eval use *is*
a problem, which is why you are worrying about p52p6.
Yours, &c, Tony Olekshy
