>>>>> "TO" == Tony Olekshy <[EMAIL PROTECTED]> writes:
>> As for legacy. I strongly urge that Modules _never_ die.
>> It is extremely rude.
TO> The contract between a module and its client is beyond the scope
TO> of RFC 88. However, I take it from your strong stance that you
TO> wrap every ++$i in an eval and handle $@ in case the CPU throws
TO> an integer overflow, oh, and you handle errors while handling
TO> errors too, ad infinitum. There, you see, is the core problem:
TO> modules or any other code cannot *guarantee* to "_never_" die.
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.
There are many other situations where I really don't need to be
careful, since the failure mode is quite fine. It really depends
on whether I'm doing brain surgery or as simply script that will
barf at the right point and someone will see it.
>> The fact that something went wrong, doesn't mean that my 100 hour
>> complex calcuation should be terminated. The fact that I couldn't
>> send an email message may or may not be of importance in the
>> scheme of things.
TO> What would happen if the email module gets an overflow on a ++$i
TO> (or anything else dies, no matter what it calls or does)? Because
TO> you are ignoring possible problems with email (instead of properly
TO> handling them by ignoring them [sic]), your 100 hour calculation is
TO> toast even though the email didn't matter to you. You just got lucky.
TO> You should have written (contents of catch block optional):
TO> try { that_email_thing(); }
TO> catch { print "Email not sent.\n$@\nContinuing anyway...\n"; }
Still a staw man. The email is a nice feature. The log file might be
the actual official result. Especially given the way the email is like
at my client.
TO> Right. Once you have to be prepared to cope with unwinding anyway
TO> (that is, if you are actually interested in writing robust code),
TO> you might as well use the coping mechanism to pick off *only* those
TO> failure modes you are willing to cope with (by actually attempting
TO> to handle or deliberately ignore the failure). Here are the actual
TO> code differences:
The point of a module is to be useful _not_ to get in my way. If I
have to start coding in an
TO> Where's $rc? Why, it's in $@, of course. <Insert epiphany here.>
TO> So, what do you, the programmer, have to learn?
TO> A major corrollory benefit of all this is that once people make the
TO> transition to exception-based error handling, the reliability of all
TO> software goes up, because you end up with whole systems that are
TO> layered to cope with failure, instead of whole systems that depend
TO> on no-one botching an else return $rc or a ++$i, not even one.
You are preparing to force all programmers to your way of thinking?
This is not what perl is about.
I DONT WANT TO BE FORCED TO USE YOUR STYLE SIMPLY TO USE THE MODULES
IN CPAN OR THAT SHIP WITH PERL.
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
