Re: [boost] Re: any_function (callback) library

From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-04-11 21:45:53

>  > It seems to me that there are 3 types of errors that one needs to
>>  decide how to handle:
>>
>>  1) Expected errors, such as a search that fails to find anything.
>>  2) Unexpected errors, such as trying to allocate memory when there's
>>  none left.
>
>IMO "expected/unexpected" isn't a very good distinction (see
>http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/~checkout~/boost/more/error_ha
>ndling.html?rev=1.1&content-type=text/html&cvsroot=boost).
>
>I would not normally call #1 an error. I think doing so muddles the issues
>and makes it harder to understand when to use exceptions. When a search does
>not find the item sought, the search completes normally. "Not found" is
>simply one possible result of a search (e.g. std::find returns the end
>iterator). I would not normally use an exception for this. Of course there
>are operations when you want to make it a precondition that an item can be
>found, but those fall into the category of precondition violations (see
>later)

I'd agree with this.

>If we didn't "expect" to run out of memory (#2), there would be no point in
>throwing, catching, or even defining a bad_alloc exception. These errors
>fall into the category of resource allocation failures. The category is
>really "indirect preconditions that there is no practical way for the caller
>to check", but that's hard to write, and nearly everything in the general
>category is actually a resource allocation failure anyway. For these,
>exceptions are usually a good choice.

IMO there are two classes of errors: those than can be caught with 
testing and those that cannot be caught with testing. Programmer 
errors fall into the first category. Resource allocation failures and 
the like fall into the second. If you can catch the problem during 
testing use an assert, if you can't use an exception.

>  > 3) Violation of pre/post-conditions and invariants.
>
>I don't think you should glom all of these into one category.
>
>IMO, invariants and postconditions should be asserted. They are under your
>control. If your invariants are broken it's unlikely that the program can do
>any useful recovery anyway.

As you said before, it's a gamble. I'd definitely like to see this as 
an option, but I'm uncomfortable with always throwing.

   -- Jesse