Re: Exception handling?

See below...
On Wed, 23 Jun 2010 10:37:23 +0200, Giovanni Dicanio
<giovanniDOTdicanio@xxxxxxxxxxxxxxxxx> wrote:

On 23/06/2010 01:51, Joseph M. Newcomer wrote:

Note that this could be handled as

BOOL TryParse(...args...)
return TRUE;
return FALSE;

It ain't rocket science. And it isn't clear to me how handling the exception results in
"bad code".

Sure it isn't (ain't?) rocket science... but do you like a fopen that
throws an exception if the file cannot be opened? No, I prefer one
returning an error code.
As I said, systems in which APIs throw exceptions are really hard to program. Exceptions
make sense when you have deep recursion, and need to unwind an unknown and unknowable
amount of recursion all at once. And are an alternative when you have hundreds of calls
all of which being to look like
return FALSE;
The fact that you can't open a file is not an exceptional condition, and
I prefer code like:

if ( some_open_file_api(...) == error )
... do what you want... (e.g. create the file, or other stuff...)
... normal flow

instead of try/catch.

It was clearly written before: the usefulness of exceptions is inversely
proportional to the number of try/catch you use: if you clutter your
code with lots of try/catch then IMHO you are overusing (abusing)
So cluttering your code with if-statements is better? I think the point is that we want
to write code whose complexity is proportional to the task at hand.

I think exceptions should be used in *exceptional* conditions (like
David wrote before).
But one can argue that a file-open failure when the file is expected to exist is, in fact,
an exceptional case...

BTW: I like these articles from the OldNewThing blog:

"Cleaner, more elegant, and wrong"

"Cleaner, more elegant, and harder to recognize"

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
MVP Tips: