--On 22.08.2000 10:48 Uhr -0700 Glenn Linderman wrote:
>> This probably won't work. What would you return exactly? Also, there's
>> plenty of chance that the return value could interfer with the regular
>> return values of that function... This will never be possible without
>> work done by the module author so the return value plays nicely.
> ...
> Hence, exception handling (with or without catch phrases) allows the
> normal, non-error case to be coded more simply both when you don't care
> about catching errors (die), and when you do.
Hmm.. I don't know how this paragraph relates to my comments (even though
it's a nice overview of the advantages from exceptions - which I'm already
convinced of after being forced to program in Java for several years.) What
I was talking about is that I cannot imagine that the perl core itself
magically transforms exceptions into return values as someone else
requested.
> "enabling/disabling fatality for exceptions with a pragma"... if the idea
> is that control continues linearly past a throw, then sub/module authors
> must write twice the error handling logic, which is painful. If it means
No - the sub returns as if it has correctly thrown the exception, but if
the exception really propagates to the top most level, it will be ignored
instead of die'ing. This is really the same as a try/catch block around my
whole program just not that ugly.
> that the destination of the throw is bounded to some boundary, that
> boundary must be defined... so I guess that's a scoped pragma, so the
> syntax would be something like
>
> { use no_fatal_throws;
> & ignore_my_errors ( @params );
> }
>
> That's just about exactly the same length and complexity as the null catch
> phrase above, which does exactly the same job.
What I was actually requesting was a small pragma which simply turns off
all fatality, in the whole program, similar to what $SIG{__DIE__} currently
is able to do, without the need to span a try/catch block across my whole
main program - I simply do not like the look and feel of that. Even though
this has global effects, it's not necessarily evil, we should only ensure
that it cannot be used from within a .pm
--
Markus Peter - SPiN GmbH
[EMAIL PROTECTED]
