On May 24, 7:18 pm, Tom Plunket <game...@[EMAIL PROTECTED]
> wrote:
>
> FWIW, I have written fairly heavily exception-laden code in the past.
> Rarely was it worth the trouble for anything more than trivial code,
> because of all of the extra things you need to keep in mind and properly
> handle. It's probably been five years since I've typed 'try' in a C++
> program though, as proper software design tends to steer you away from
> "complex" mechanisms like exception handling anyway.
I would also argue that early in your project development, where
you're in a prototyping stage and the design is not fully nailed down,
you don't really know how exceptions should be handled. Any kind of
error handling that returns to the caller, is simply passing the buck
as a meaningless gesture. The caller isn't going to do a damn thing
about it, you aren't going to write that code. You may decide on a
good policy later, when the code has proven its utility and you know
what you really need to get from it, but not when you first write it.
There's a strong likelyhood that you'll refactor that code out of
existence or otherwise throw it away.
I write local warnings as placeholders for a possible policy. That's
mainly to record my thoughts about the case logic. Debug logs are
useful, but passing errors up the call chain isn't. Most of the time
it's a verbose way of saying, "I have no idea what to do, please crash
me."
When the design is stable, I'll clean up the error handling and the
API for public consumption.
Cheers,
Brandon Van Every
|
