Is try-catch block a way to prevent a crash?

[Curious]

Hi,

I've found that if I wrap my code with a try-catch block in the
fashion illustrated below, it'll do what is specified in the catch
section instead of crashing. Could anyone confirm that this is true?

If it's true, I'll modify every single method in my program to wrap it
with a try-catch block to prevent it from crashing.

FYI, the try-catch block I mentioned is as below:

void SomeMethod()
{
try
{
// Do something

}
catch (Exception e)
{
logger.Write (e.Message);
}

}

 

[Jack Jackson]

Hi,

I've found that if I wrap my code with a try-catch block in the
fashion illustrated below, it'll do what is specified in the catch
section instead of crashing. Could anyone confirm that this is true?

If it's true, I'll modify every single method in my program to wrap it
with a try-catch block to prevent it from crashing.

FYI, the try-catch block I mentioned is as below:

void SomeMethod()
{
try
{
// Do something

}
catch (Exception e)
{
logger.Write (e.Message);
}

}

Yes, that is what Try/Catch does.

However, wrapping every single method like that is probably a really
bad idea. What if the caller of the method expects the method to do
something, what will happen when it either doesn't do anything, or
maybe worse, does half of it.

 

[Curious]

Hi Jack,

I get the idea. I'll look at each method carefully to make sure they
do what they're supposed to.

I'll wrap the methods with a try-catch block to prevent any crash.

 

[Marc Bernard]

Hi Jack,

I get the idea. I'll look at each method carefully to make sure they
do what they're supposed to.

I'll wrap the methods with a try-catch block to prevent any crash.

You should really read this first:

http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx

Marc
http://nomagichere.blogspot.com

 

[Jon Skeet [C# MVP]]

I get the idea. I'll look at each method carefully to make sure they
do what they're supposed to.

I'll wrap the methods with a try-catch block to prevent any crash.

No, please don't. It doesn't mean your code will work better - it just
means it will fail fairly silently and keep going *in error
conditions*.

When an exception happens, most of the time the calling code won't be
able to sensibly recover and complete the operation. For instance, if
you're trying to return a web page and something goes wrong, your best
course of action will be to display an error page - not plough on
regardless of the error.

Error handlers are usually at the top level of the application, or in
*very* specific circumstances where you can actually work round the
error (or retry, etc).

Wrapping every method in try/catch is a recipe for disaster, as well as
making your code much harder to understand.

 

[Michael Justin]

Curious wrote:

I get the idea. I'll look at each method carefully to make sure they
do what they're supposed to.

I'll wrap the methods with a try-catch block to prevent any crash.

Some exceptions will not lead to a crash, this can be even worse. For
example, when an exception occurs in BackgroundWorker(DoWork event) - it
behaves as though happened nothing. So the application logic fails,
without a visible hint.

How to catch Exception in Background Worker
http://devintelligence.com/blogs/netadventures/archive/2005/07/17/1096.aspx


Another hint: AppDomain.CurrentDomain.UnhandledException will not catch
Exceptions in WPF applications. WPF requires a different way to catch
unhandled exceptions, using app.DispatcherUnhandledException


Maybe there are even more pitfalls in the Framework...


Hope this Helps(tm)

 

[clintonG]

Yes, --every-- will also impose significant performance impacts I
understand. In your opinion Jon which circumstances have motivated you to
draw that fine line when and where try-catch-finally is best used and how to
elegantly respond? And how do you use finally to its best advantage?

 

[Jon Skeet [C# MVP]]

Yes, --every-- will also impose significant performance impacts I
understand.

Well, possibly. It limits what the JIT compiler can do, but the actual
wrapping with try/catch doesn't cost anything. There's cost to catching
an exception just to rethrow it, however.

In your opinion Jon which circumstances have motivated you to
draw that fine line when and where try-catch-finally is best used and how to
elegantly respond? And how do you use finally to its best advantage?

My "finally" blocks are almost always invisible due to the "using"
statement.

I rarely write "catch" blocks unless either:
a) I'm at some notional "top level" where it's appropriate to
log/report the error
b) I know about the error in advance and can handle it (but not avoid
it in the first place)
c) I wish to catch and wrap it

 

[Curious]

After reading your posts, I feel it's very difficult to handle
exceptions. Since my code is so complicated, I don't know what to do
to handle so many possibilities of exceptions.

I post a simple method here, could anyone kindly show me how to handle
exception in this piece of code?

void ReadBearTable()
{
try
{
StreamReader sr = new StreamReader(new FileStream("C:\
\Temp\\Bear.tkr", FileMode.Open, FileAccess.Read));
string line = sr.ReadLine();

while (line != null)
{
mBearList.Add(line);

line = sr.ReadLine();
}

sr.Close();
}
catch (Exception e)
{
logger.LogMessageBarMessage(ESeverity.Error,
e.Message);
}
}

 

[Stephany Young]

Ummmmm .... You've handled it!

 

[Jon Skeet [C# MVP]]

After reading your posts, I feel it's very difficult to handle
exceptions. Since my code is so complicated, I don't know what to do
to handle so many possibilities of exceptions.

The fundamental question is: how serious is the problem? Can you
continue?

I post a simple method here, could anyone kindly show me how to handle
exception in this piece of code?

Well, why are you catching it here? Are you happy that any caller who
calls your ReadBearTable method won't know whether or not it's
completed successfully? Or is it likely to be a critical error which
really means your program can't continue? Should you let the caller
decide instead of you just swallowing the exception?