Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-04-12 07:37:27

From: "Jesse Jones" <jesjones_at_[hidden]>

> >IMO "expected/unexpected" isn't a very good distinction (see
> >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
> >and makes it harder to understand when to use exceptions. When a search
> >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
> >are operations when you want to make it a precondition that an item can
> >found, but those fall into the category of precondition violations (see
> >later)
> I'd agree with this.

The paper is good, but "Yes, if you want and can afford stack unwinding" is
only one of the possible answers to "Should I throw an exception in this

I'd also add these as possible answers:

"Yes, if this simplifies client code considerably"; (eliminated return code
"Yes, if you have to abort a long chain of operations";
"Yes, if there is no other alternative". (constructor failures)

IOW, to apply this to the "not found" situation above:

for(; first != last; ++first)
    if(found(*first)) f(*first); else g(*first);

-- an exception is not appropriate, the 'not found' situation has O(n)

for(; first != last; ++first)
    if(!found(*first)) f(*first); else break;

-- an exception may be appropriate, the 'not found' situation has O(1)

std::for_each(first, last, call_f_if_found);

-- an exception is the only way to 'break' from for_each.

About using 'assert' in a library: there's also the ODR problem to worry

Peter Dimov
Multi Media Ltd.

Boost list run by bdawes at, gregod at, cpdaniel at, john at