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
