|
Boost : |
From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-03-15 05:38:51
>Thu, Mar 15, 2001 at 10:45:15PM -0800, Jesse Jones ¤:
>> 2) CloseHandle can also fail, but you don't want to throw from a dtor so an
>> assert might be good.
>
>Is there any difference? Throwing from destructor has at worst case the same
>effect as failed assertion; but assert usually disappears from release
>builds,
>and throw's not.
Throwing from a dtor is liable to terminate your app. Asserting will let you know something is wrong and let the app continue. This may well be OK since you're all done with that handle anyway.
>> 6) It's better to provide an operator const void*() method instead of
>> operator bool(). (Unlike bool the const void* one won't implicitly convert
>> to umpteen different types).
>
>For the same reason I'm against implicit conversions when there is no real
>need for them; why not to provide just member function?
Many people like writing stuff like "if (p)". And the const void* conversion operator is surprisingly safe.
>> 7) I don't think the locker classes should themselves throw exceptions. The
>> only way to get this to happen is for the programmer to do something nasty
>> like call unlock too many times. But this is a straight forward programmer
>> error, not a runtime error, so it seems like an assert is the answer.
>
>Assert is primarilly debug tool, and library cannot depend from mode it is
>compiled - debug mode or release mode. It is what std::logic_error (as base
>class) is for.
That's one opinion. Another is that there are two more or less distinct classes of errors: system errors like out of memory or writing to a locked file and programmer errors like indexing past the end of an array. Exceptions work well for system errors, but they're often overkill for programmer errors. I *really* don't want every pre/post condition violation and sanity check to throw an exception for every app I write. Ideally boost would provide a better assert, but in the meantime the C assert has a place in boost and I think this may be one of them.
-- Jesse
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk