Chaim Frenkel wrote:
> >>>>> "GL" == Glenn Linderman <[EMAIL PROTECTED]> writes:
>
> >> Neither is EOF on a file, or working with an empty list. Adding all these
> >> exceptions for non-exceptional and quite common scenerios is bothersome.
>
> I don't know where this idea of a _normal_ situation is considered
> exceptional.
The idea of a _normal_ situation being considered exceptional is raised when the
code written inappropriately handles some of the normal return values.
The original example of bad code John Porter wrote:
> > $foo = "flabergasted";
> > substr($foo, index($foo, 'abc'), 20); # Returns undef
>
contains errors. Clearly the current index, or even index modified to return
undef, doesn't produce the desired results. The inappropriate value of -1 (or
undef) passed as the 2nd parameter to substr will produce erroneous results.
In order to make the above line useful, index would need to alter the _normal_
flow of control by throwing an exception. However, this is a different index
function than we have today. The author of lines like the above should use a
wrapper around index that throws exceptions for the normal cases that are not
desirable for his application. Then the above terse code could be usefully
employed.
The real question boils down to who decides what is normal and what is
exceptional. This is the conundrum of programming today.
> I don't want to sprinkle my code with try/catch just to handle a
> 'normal' situation.
I don't want you too, either.
(1) RFC 119 only requires the "catch", not the "try". This solves half the
problem :)
(2) I want you to use the appropriate code in the appropriate ways, so that your
catch blocks only catch the abnormal (exceptional) situations. And for abnormal
situations, the default catch handlers might serve you just fine, solving the
other half of the problem, much of the time.
> GL> I agree with your concern that exception handling is (generally)
> GL> more expensive than error codes. However, I see it as a good
> GL> expenditure of the fast CPUs of today, as a tradeoff towards
> GL> reliable processing. And maybe in Perl6 exception handling could
> GL> be less expensive than it is (by comparison to error codes) in
> GL> other languages? That's a question for the internals guys, of
> GL> course.
>
> A cycle here a cycle there, and soon the program becomes bloatware.
Right. Different people have different opinions about this, too. Where to spend
those cycles most usefully. My preference (but only a preference) is to see
cycles expended toward making simple things more reliable. Smart programmers can
solve the complex problems, but in doing so often overlook or assume away error
handling... by making error handling noisier (via exceptions) but also moving it
out of the main code path (via catch blocks) produces a result that pleases me,
and avoids cluttering the main path of code with the handling of abnormal things.
The cost then is paid only when something abnormal happens, not for every normal
thing that might happen but wasn't expected here.
--
Glenn
=====
Even if you're on the right track,
you'll get run over if you just sit there.
-- Will Rogers
____________NetZero Free Internet Access and Email_________
Download Now http://www.netzero.net/download/index.html
Request a CDROM 1-800-333-3633
___________________________________________________________
