Where to start the try block and what's the overhead???

  • Thread starter Thread starter Bob Rock
  • Start date Start date
B

Bob Rock

Hello,

this is something I've been asking myself for sometime ... and now I'd like
to clarify this point.
When should the try block start in a method??? What I mean is, does having
all the code instead of a smaller set of it inside a try clause add any
overhead??? 1What I'd like to understand is if, to be completely sure that
no unhandles exception will get to the user, I can place all the code inside
a try block
and if this practice adds unnecessary overhead (memory usage, more cpu
cycles, etc.) or if having a smaller set of instructions instead of all the
code under a try has the EXACT SAME effect on resources (overhead).


Bob Rock
 
try blocks add overhead when they are fired or spring into action. Otherwise
they don't. The issue with wrapping a big nasty try block is that you aren't
really able to tell what entity fired the exception.

The implicit assumption in a try block is that you are prepared to handle a
particular type
of exception. A big all encompassing try block defeats that purpose since
your code cannot possibly be prepared to handle any and all exceptions. In
fact, I am a proponent of letting certain exceptions
blow the application apart - a stack overflow or memory exhaustion exception
are good examples of that.
 
Alvin is pointing out a very important design principle. Exception handling is
meant
for two purposes, reporting and recovery. You should handle exceptions if you
need
to report them, and only then crash out or exit the app gracefully. You should
also
handle exceptions if you think you can recover from them.

Note that in the case of a stack overflow or out of memory exception you may not
be
able to gracefully shut-down your application. The best you can do is an
Environment.Exit
with some error code in the instance your code is being automated.

--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

Alvin Bruney said:
try blocks add overhead when they are fired or spring into action. Otherwise
they don't. The issue with wrapping a big nasty try block is that you aren't
really able to tell what entity fired the exception.

The implicit assumption in a try block is that you are prepared to handle a
particular type
of exception. A big all encompassing try block defeats that purpose since
your code cannot possibly be prepared to handle any and all exceptions. In
fact, I am a proponent of letting certain exceptions
blow the application apart - a stack overflow or memory exhaustion exception
are good examples of that.

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok
Bob Rock said:
Hello,

this is something I've been asking myself for sometime ... and now I'd
like
to clarify this point.
When should the try block start in a method??? What I mean is, does having
all the code instead of a smaller set of it inside a try clause add any
overhead??? 1What I'd like to understand is if, to be completely sure that
no unhandles exception will get to the user, I can place all the code
inside
a try block
and if this practice adds unnecessary overhead (memory usage, more cpu
cycles, etc.) or if having a smaller set of instructions instead of all
the
code under a try has the EXACT SAME effect on resources (overhead).


Bob Rock
Click to expand...
Click to expand...
 
Bob,
In addition to the other's comments.

Normally I only include Try/Catch blocks in methods, when I know there is
something specific that I need to do with the exception. For example the
method may cause an UnauthorizedAccessException, and the
UnauthorizedAccessException is O.K. and I should just continue processing.

More likely is I will have Try/Finally blocks in methods to clean up
resources. In C# the using statement makes this easier. For example if I
opened a connection to a database, I would use a Try/Finally to ensure the
connection is closed when the method exits.

For most exceptions I simply let the global exception handler deal with the
exception, which normally includes logging the exception, and possible email
notification.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your app, as
well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why & when you
use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/issues/04/06/default.aspx

Unfortunately the article is not on-line yet.

Hope this helps
Jay
 
Back
Top