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

>>>>> "TO" == Tony Olekshy <[email protected]> writes:

TO> Chaim Frenkel wrote:
>> 
>> You are being extreme here.  I use perl _because_ it is so
>> forgiving.  I can easily do unlink("foo.err") and not check
>> return codes because I don't care if it was there before.

TO> No sir, I am not being extreme.  Don't C<use fatal;> and don't use try/throw/catch/finally, and
TO> nothing I'm talking about changes
TO> anything you are used to doing.  I went to a large amount of trouble
TO> to minimize the impact of RFC 88 on existing Perl 5 code; there is
TO> almost none ($@ and @@ are now read-only and contain Exception
TO> objects -- that is all).  This is explained clearly three times in
TO> RFC 88, once right in the ABSTRACT.  I don't know what else I can say.

You haven't. What happens when Graham Barr decides to use throws in
his Net::* modules. These are some of the most useful modules that
I have been using. 

You have now forced me to switch to try/catch.

TO> Public APIs to core modules should respect the current state of
TO> <use fatal;>, by using the following construct for error returns:

TO>     return $FATAL_MODE ? ERROR_IO : throw Error::IO;

Why make all module authors do that? Have core perl do that for you.
Make a pragma that would treat throw as a return. No cost to the
module author.

TO> I have probably written Perl code on at least half the days of
TO> my life for the last 10 years.  Much of that code has been one-
TO> liners or simple scripts.  I *don't* want to change how Perl
TO> does those.  Much of that code has been applications containing
TO> hundreds of files.  I want to change how easy Perl makes it to
TO> do those well.

But you are.

<chaim>
-- 
Chaim Frenkel					     Nonlinear Knowledge, Inc.
[email protected]				               +1-718-236-0183