Try Catch Exception Question

[Matt]

Are Case #1 and Case #2 the same? It seems functionality identical? If they
Or which one is better? Please advise. Thanks!!

case #1:
=======
try
{ //code1
}
catch(...)
{ //catch for code1
}

try
{ //code2
}
catch(...)
{ //catch for code2
}

case #2:
=======
try
{ //code1
//code2
}
catch(...)
{ //catch for code1
}
catch(...)
{ //catch for code2
}

 

[Roedy Green]

case #2:
=======
try
{ //code1
//code2
}
catch(...)
{ //catch for code1
}
catch(...)
{ //catch for code2
}

no, it works like this:

try
{
//code1
//code2
}
catch( IOException e )
{
//catch for code1 and code2 IOExceptions
}
catch( IllegalArgumentException e )
{
//catch for code1 and code2 IllegalArgumentExceptions
}

 

[Chris Smith]

Are Case #1 and Case #2 the same? It seems functionality identical? If they
Or which one is better?

They are not identical if the catch block for code1 can complete
normally. In that case, the difference is whether code2 is executed
when an exception occurs in code1. Which is better depends on what
behavior you want.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Andy Fish]

They are not identical if the catch block for code1 can complete
normally. In that case, the difference is whether code2 is executed
when an exception occurs in code1. Which is better depends on what
behavior you want.

That's true but I think there are also cases when case 2 can provide better
readability.

For example if you're doing several bits of SQL intermingled with several
bits of file I/O and if anything goes wrong all you're going to do is wrap
the exception and throw it back up.

In this case I would be tempted to put it all inside one try block and catch
SQLException and IOException at the end. I'm not suggesting you should catch
Exception or Throwable though.

 

[Hylander]

That's true but I think there are also cases when case 2 can provide better
readability.

For example if you're doing several bits of SQL intermingled with several
bits of file I/O and if anything goes wrong all you're going to do is wrap
the exception and throw it back up.

In this case I would be tempted to put it all inside one try block and catch
SQLException and IOException at the end. I'm not suggesting you should catch
Exception or Throwable though.

There are cases where you want separate recovery type events too of
course. Having them in separate methods seems even better. (one
refactoring heuristic says that whenever you start commenting code
"code1" and "code2", separate them out into methods. Part of the "Do
one thing, do it well" rule of thumb) With the separate calls/blocks,
you have more flexibility overall (you can do either actually in terms
of making sequential dependency or transactional, recovery steps
etc.). Longer code isn't always more readable. esp if code 1 and code
2 were both already quite long.

 

[Adam Maass]

Are Case #1 and Case #2 the same? It seems functionality identical? If they
Or which one is better? Please advise. Thanks!!

case #1:
=======
try
{ //code1
}
catch(...)
{ //catch for code1
}

try
{ //code2
}
catch(...)
{ //catch for code2
}

case #2:
=======
try
{ //code1
//code2
}
catch(...)
{ //catch for code1
}
catch(...)
{ //catch for code2
}

Almost but not quite identical.

In case 1, code1 is attempted to be executed. Should it raise an exception,
its catch is executed. Then code2 is attempted, and should it raise an
exception, its catch is executed. Note that code2 is always attempted to be
executed.

In case 2, code1 is attempted to be executed. Should it raise an exception,
the catch for code 1 is exeucted, skipping code2. If it does not raise an
execption, then code2 is executed. Should it raise an exception, then the
catch for code2 is executed.


Which is preferable? Generally speaking, case 2. If an exception occured in
code1, then executing code2 probably doesn't make much sense. There are,
however, exceptions [ha-ha], so YMMV.


-- Adam Maass