I look at exceptions as communicating “out of band” information. In
the case of sysread(), the “in band” information is the data you’re
reading. Everything else (EOF, failures, etc.) is out of band.
If you don’t use an exception you have to test all over the place.
This can also require status codes to be passed up several levels.
The main impetus behind using exceptions is this:
- we can detect exceptional conditions easiest at the lowest levels
(in this case, inside sysread).
- but the callers of these low-level routines generally don’t know
what the policy for dealing with the exceptional conditions is
- so we want some caller, possibly quite a bit up the caller chain, to
- but this would require passing status all the way back up, or
(worse) testing status at higher levels
So it’s no accident that Ruby, Smalltalk, C++, and Java (I don’t know
about the specifics of exception handling in CLU, Ada, or PL/I) ended
up with essentially the same exception model (except, of course, that
most Smalltalks allow resumption as well as termination).
Another point is that code using exceptions is generally smaller and
faster than code using status code propagation.
On Monday 08 July 2002 05:40 am, Austin Ziegler wrote:
On Mon, 8 Jul 2002 14:47:25 +0900, Sean Chittenden wrote:
Thanks all for the answers. Does it strike anyone as bad
practice to use a rescue for control flow? I thought a more
explicit test method would have been provided.
My C roots tell me, yes, but my Ruby roots tell me no. Having an
exception thrown/caught is okay practice in Ruby.
It still seems wrong to me, since an end of file condition is an
expected situation, not an exceptional situation.
GPG key ID: BEEA7EFE