>>>>> "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.
GL> Now the loop works fine, but somehow, we need to get out of the
GL> loop when we encounter an error, or end-of-file. Many programs,
GL> including many perl programs, actually do this incorrectly, but it
GL> is "good enough" most of the time: they treat _all_ errors during
GL> file reading as end-of-file. This is _not_ good enough all of the
GL> time, but we're not writing airplane controls most of the time
GL> either, but we should stay aware of the issue, even though we
GL> usually ignore it.
[snip]
All irrelevant, I am not arguing about having a disk error raising
an excpetion. I don't want EOF raising an exception.
I don't want
$foo = "xyz"
$foo =~ /abc/;
raising an exception.
GL> File handling is pretty obvious: usually you get data, not EOF, so
GL> it is pretty obvious where the exception handling should go. But
GL> regarding the "index" method, I agree that some of the time you
GL> are searching for the existance of a string, and you don't really
GL> expect to find it -- that neither finding it, nor not finding it
GL> is unexpected. In the example John coded, with the result of
GL> "index" being passed directly to "substr", it would be better if
GL> index threw an exception on error. But in other situations where
GL> index might be used, that wouldn't always be true. "index" is one
GL> of those functions that has multiple outcomes some or all of which
GL> might be acceptable in some circumstances, and some or all of
GL> which might be unacceptable in some circumstances. And that is
GL> the true conundrum: the function as written is not as convenient
GL> to use in all circumstances as it could be.
I don't know where this idea of a _normal_ situation is considered
exceptional.
I don't want to sprinkle my code with try/catch just to handle a
'normal' situation.
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.
This is what some of the p5pers have been voicing about what has
been happening with the latest releases.
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
