"Karl Bochert" <kbochert@copper.net> wrote in message news:1103_1080855541@bose...
> On Thu, 01 Apr 2004 13:36:08 -0600, Brad Anderson <brad@dsource.dot.org>
wrote:
> >
> >
> > Karl Bochert wrote:
> >
> >  > If complex error handling is needed, I would refactor or do something
> > like:
> >  >     try {
> >  >         if (err) {
> >  >             <pre_cleanup>
> >  >             throw <myerr>
> >  >             }
> >  >     }
> >  >     catchall {
> >  >         if (curerr == ioerr)  <cleanup_io>
> >  >         else if (err == myerr ) <cleanup>
> >  >         else throw <curerr>
> >  >      }
> >
> >
> > in your example above, for 'try { }', the 'if (err) { }' portion is
> > built in.  That's what try { } does, it automatically has a 'if (err) {
> > }'.  The code to execute in the 'if (err) { }' is contained in the
> > 'catch (err) { }' block.
>
> Then I don't understand at all!

Well, the way I think about it is that the 'try' phrase brackets the set of statements that I'm interested in trapping errors for. This could mean one, two, or any number of statements but the corresponding catch phrases will only get invoked if there is an error thrown for ANY of the bracketed statements.

The 'finally' phrase collects together the cleanup code that is required for EVERY type of error rather than specific types of errors. If we didn't have the 'finally' option, then we would have to repeat code for specific type of error trapped.

Something like ...

  try{ <whatever> }
   catch(ioerr) { <commonCleanup> <ioCleanup>}
   catch(myerr) { <commonCleanup> <myCleanup>}
   catch(assertErr) { <commonCleanup> <assertCleanup>}
   catch() { <commonCleanup> }

rather than

  try{ <whatever> }
   catch(ioerr) { <ioCleanup>}
   catch(myerr) { <myCleanup>}
   catch(assertErr) { <assertCleanup>}
   finally {<commonCleanup>}


If the common cleanup code was extensive, this could lead to a maintenance headache.

>Some piece of code thows an error, and it only does so when there is an
error
> to thow.  Therefore the 'if(err) throw' -- you don't want to throw if
there is no error.
> The above case is a little unusual (i think) in that the same function is
both throwing and catching its own error.
> (Thats all one function)
> The throw statement walks back the stack looking for a catch to handle it.
> If the 'finally' is meant to cleanup before the throw starts its walk,
then the cleanup can be inserted before the
> throw as above.  Alternatively the thow could begin its walk at the
current subroutine, which could catch its
> own throw and cleanup there. either way, the finally clause is
superfluous.
>
> Why should there be a try clause?
>
>     foo()
>    {
>        <code1>
>        <code2>
>        if (somethings_wrong)  throw;
>        <code3>
>        catch {
>             if (myerr)  <cleanup and re-throw>
>         }
>     }

The 'try' is used to explicitly define the set of statements that are associated with specific catch phrases. Without 'try' the compiler would not know which set of catch phrase to branch to when an error is thrown.

Consider...
   try{
    <code1>
    <code2>
    }
   catch (myerror) { . . .}
   <code3>
   try {
    <code4>
   }
   catch (errorX) { . . . }

And now without 'try'.

  <code1>
  <code2>
  catch(myerror) { ... }
  <code3>
  <code4>
  catch(errorX) { ... }

The difference is that in the code with 'try', <code3> is not subject to any catch phrases, but in the code without 'try', one cannot see, or even do, that.


Sometimes, when debugging, I put a try/catch on each statement to find some bugs. Especially 'access violation' ones.

  try{ <code1> } catch {printf("DEBUG A\n");}
  try{ <code2> } catch {printf("DEBUG B\n");}
  try{ <code3> } catch {printf("DEBUG C\n");}
  try{ <code4> } catch {printf("DEBUG D\n");}
  try{ <code5> } catch {printf("DEBUG E\n");}

Nasty, but it does help. Of course it would be nice to have 'access violation' messages give a file and line number ;-)

> What does putting <code2> and the throw in a try clause accomplish?
>
>
> >
> >  > Come to think of it, what does 'try' accomplish?
> >
> >
> > I have found that once I got used to the try-catch-finally, it's like cocaine (You can't do without it).  It helps you get closer to bullet-proof code.
> >
> Perl programmers say the same thing about all manner of obfuscatory
features :-)

As to Bach coders too, I believe...

-- 
Derek