The new std.process is ready for review
Jonathan M Davis
jmdavisProg at gmx.com
Sun Mar 3 05:00:14 PST 2013
On Sunday, March 03, 2013 12:11:16 deadalnix wrote:
> On Tuesday, 26 February 2013 at 18:48:08 UTC, Jonathan M Davis
> > I think that it's far more correct to say that exceptions are
> > for situations
> > where it's reasonable for code to assume that something's the
> > case when it
> > might not be or when it's impossible for it to check. For
> > instance, it's much
> > cleaner to write a parser if the parser in general assumes that
> > operations
> > will succeed and throws when they don't. Then only a small part
> > of the parser
> > needs to worry about handling error cases. Or an example of
> > when it would be
> > impossible to check would be with file operations. You can (and
> > should) check
> > beforehand that the file exists, but there's no way to
> > guarantee that the file
> > will still exist when you actually operate on it (e.g. another
> > process could
> > delete it out from under you), so the file functions have to
> > throw when the file
> > isn't there anymore or you don't have permissions or whatever.
>
> That is best explanation I've read on the subject. I'm dead
> serious.
Well, if you have to debate exceptions and/or explain them enough times, you
start coming up with better explanations, or you never get anywhere, and the
whole "exceptional circumstances" bit is just way too vague, and everyone
interprets it differently. And too often, I've argued exceptions with someone
who basically agreed with my opinion, but we both sucked at explaining what we
meant, so we ended up arguing until we understood that. It's definitely one of
those cases where examples make things clearer, and if you can distill what
the examples have in common, well then you get an explanation like what I
gave.
> I want to add a point that you don't address here : it is easy to
> forgot to check return value. For instance, how much C code don't
> check the return value of printf ? I'd be surprised if it is even
> 1% . When you don't, and things fail, you program is in undefined
> state and start doing crap.
Definitely, that is one of the reasons that error codes are generally horrible.
> As exception are costly only when the
> are thrown, it don't make any sense to not use them for speed, as
> doing crap very fast is rarely a goal that people want to achieve.
The place that it makes sense to not use them when speed is a concern is when
they're going to be thrown often or when the code in question simply cannot
afford the extra time that that the exception costs even in the rare situations
where one actually gets thrown (which is the sort of situation that games
might run into given their insane performance constraints but most everything
else won't). Also, I don't believe that the cost of try-catch blocks is
actually zero (though it _is_ relatively low), even when no exceptions are
thrown because of stuff that must be done in case an exception is thrown, but
it's definitely true that in most cases, not using exceptions because of
performance concerns is a mistake, and if your code is really going to be
throwing exceptions enough that it would be a performance concern, then using
an exception doesn't make sense anyway. That's back to using exceptions as flow
control.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list