It is very easy to misuse exceptions. They are designed to handle
exceptional events. Do not use them to handle the standard program
flow.
I can't quite tell from what you've described, but it sounds like you
might be erring on toward the latter.
There are two reasons to use them only for exceptional cases:
1) Performance. This shouldn't really matter, but it can. I once ran
into some code that threw its result (reading a character) instead of
returning it. The code was approximately 100x slower as a result.
2) Flow. Exceptions unroll the stack to the next handler, everything
in between is skipped. This is why they're so well suited for
handling exceptional cases: you don't have to clutter up all the
intervening code with the rare edge case. But the converse is also
true: if you force normal events into exceptions, you end up losing
the benefit of exceptions (collapsing the orthogonal flows into one
fragile one -- accidentally leave out a try/catch block and enjoy the
hilarity of finding the bug) and muddying up your code with
superfluous try/catch blocks.
If driver_return_code_t is really always either SUCCESS or an
exception, then exceptions are good here. If it's used for
determining normal status, beware.
-P
On 1/15/06, R. Bernstein <[EMAIL PROTECTED]> wrote:
> I've been working a little on wrapping libcdio for Python using SWIG
> and one of the things I realized in the OO C++ wrapper was that
> perhaps it would be more C++ idiomatic to raise exceptions on device
> errors rather than give the status as a function return.
_______________________________________________
Libcdio-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/libcdio-devel
