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...)
{
try
{
Parse(...);
return TRUE;
}
catch(..whatever..)
{
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
if(!f())
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)
exceptions.
****
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"
http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx

"Cleaner, more elegant, and harder to recognize"
http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx


Giovanni
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.



Relevant Pages

  • Re: Problems with Tesco
    ... and if rocket science clearly demonstrates that 5 minutes is ... ample time in which to buy a newspaper or a lottery ticket, ... jobsorths do not list reason as one of their strong ... exceptions. ...
    (uk.legal)
  • Re: Exception handling?
    ... It ain't rocket science. ... 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 exceptions. ... "Cleaner, more elegant, and harder to recognize" ...
    (microsoft.public.vc.mfc)
  • Re: OOP php user system
    ... and TRY/CATCH maybe. ... bool res = f.SetI; ... especially if the exceptions can only be identified by text strings. ... me the 'i' in iTeachersPerStudent isn't the amateurist's mistake of using ...
    (comp.lang.php)
  • Re: How expsensive in terms of performance is try / catch
    ... Both of your examples have the same number of try/catch blocks. ... if each try/catch block reduced performance, ... try/catch blocks that simply eat exceptions are bad. ... your own code, but you can't avoid dealing with them altogether, and ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: new without delete: what will happen
    ... If you're writing try/catch a lot, you're probably not using exceptions ... The idea is to have destructors of local objects perform ...
    (microsoft.public.vc.mfc)