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