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

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);
}

}

On Thu, 12 Jun 2008 19:12:36 -0700 (PDT), Curious
<fir5tsight@xxxxxx> wrote:
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.

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.

On Jun 13, 8:32*am, Curious <fir5tsi...@xxxxxx> wrote:You should really read this first:

http://msdn.microsoft.com/en-us/libr...exception.aspx

Marc
http://nomagichere.blogspot.com

Curious <fir5tsight@xxxxxx> wrote: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.

--
Jon Skeet - <skeet@xxxxxx>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

Curious wrote:

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/net...7/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)
--
Michael Justin
SCJP, SCJA
betasoft - Software for Delphiâ„¢ and for the Javaâ„¢ platform
http://www.mikejustin.com - http://www.betabeans.de

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);
}
}

Ummmmm .... You've handled it!


"Curious" <fir5tsight@xxxxxx> wrote in message
news:041d714b-7a8e-47be-be64-32a5c1a926a2@xxxxxx

Curious <fir5tsight@xxxxxx> wrote:The fundamental question is: how serious is the problem? Can you
continue?
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?

--
Jon Skeet - <skeet@xxxxxx>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com