Exception handling

[Anirudha Vengurlekar]

Hello Community,



We can have nested TRY , CATCH , FINALLY blocks in the application. So in
what situation (in a class or in a function) I would use this nested Try
catch blocks? If someone would help me then it would be great. ( I know why
we use the Try catch etc., but I am looking in what scenario someone can use
nested Try catch for better exception handling )



Thanks

 

[Vadym Stetsyak]

with nested try-catch-finally constuct you can protect some particular
action (method call, etc)
and if that action fails than in catch perform some alternative actions...

Here is some arbitrary scenario:

public void MethodOneCall()
{
SomeResource rc = new SomeResource();
try
{
try
{
rc.Open();
DoSomethingWithResource(rc)
}
catch
{
DoSomethingOther();
throw new Exception("Log me please");
}

}
catch(Exception ex)
{
//smth Bad happened
LogIt(ex.Message);
}
finally
{
if ( rc != null && rc.IsOpen )
rc.Close();
}
}

However using exceptions does great harm to application performance, that's
why it is better to use them only when there nothing left to do.

 

[Anirudha Vengurlekar]

Thanks a lot this make sense.

with nested try-catch-finally constuct you can protect some particular
action (method call, etc)
and if that action fails than in catch perform some alternative actions...

Here is some arbitrary scenario:

public void MethodOneCall()
{
SomeResource rc = new SomeResource();
try
{
try
{
rc.Open();
DoSomethingWithResource(rc)
}
catch
{
DoSomethingOther();
throw new Exception("Log me please");
}

}
catch(Exception ex)
{
//smth Bad happened
LogIt(ex.Message);
}
finally
{
if ( rc != null && rc.IsOpen )
rc.Close();
}
}

However using exceptions does great harm to application performance, that's
why it is better to use them only when there nothing left to do.

 

[Kevin Cline]

However using exceptions does great harm to application performance, that's
why it is better to use them only when there nothing left to do.

Has Microsoft documented this? Have you measured it?

Very few C# applications are compute-bound -- most are limited by I/O.
For those applications the time to handle an exception is negligible.

Applications that are that sensitive to the time needed to handle an
exception might be better written in C++.

 

[Dave]

"Vadym Stetsyak" <[email protected]> wrote in message

Has Microsoft documented this? Have you measured it?

The mechanism itself is documented. It is built on top of the Win32
Structured Exception Handling (SEH); Matt Pietrek wrote the definitive
article on this in MSDN here:
http://www.microsoft.com/msj/0197/Exception/Exception.aspx

Chris Brumme has written extensively on how the CLR mapped their support for
exceptions onto SEH here
http://blogs.gotdotnet.com/cbrumme/commentview.aspx/d5fbb311-0c95-46ac-9c46-8f8c0e6ae561

The bottom line is that when an exception is generated it first goes to the
kernel, then back up to user mode where the debugger gets a crack at it,
then a two-pass stack walking mechanism locates a catch handler, but before
the handler is invoked all intervening finally blocks are executed (with
potentially unbounded code being executed) and the stack unwound all before
the catch handler ever gets to run. By definition the path between the line
of code that generates the exception and the line of code that executes in a
catch handler is non-local; performance demands that code paths be local to
avoid paging, cache misses, kernel mode transitions, context switches, etc.

Very few C# applications are compute-bound -- most are limited by I/O.
For those applications the time to handle an exception is negligible.

Depends. If a piece of code is sitting a tight loop calling a method that
throws exceptions then you will definitely notice the performance impact.

Applications that are that sensitive to the time needed to handle an
exception might be better written in C++.

The SEH mechanism is practically the same so you wont get much benefit from
coding in C++ (all other things being equal). The real distinction depends
on how the component is intended to be used. If it is part of a manual
operation or if low-performance is suitable then exceptions are great; if it
is intended to be high-performance than exceptions should only be used for
exceptional conditions.

Dave