try-catch - but a catch which catches everything

[Benny]

Hi,

I have something like this:

try
{
// some code
}
catch // note - i am catching everything now
{
// do something
}

Will this sort of catch statement, catch 'unsafe' and 'kernal-level'
exceptions (even if the app is a simple asp.net app with no unsafe stuff)?
(just wanted to confirm as I had a debate with one of my friends - AFAIK i
feel it doesn't since no unsafe code is used and since Win32 exceptions are
mapped into managed .NET exception classes)
Also, in many cases, i have catch blocks which does nothing - because i
don't want any exception to be propagated...so mething like follows.

public bool IsInteger(strin g val)
{
bool result;

try
{
int.Parse(val);
result = true;
}
catch
{
result = false;
}
return result;
}

Is this OK (a good practice)?

Thanks,
Benny

[Scott Roberts]

"Bruce Wood" <br*******@cana da.com> wrote in message
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

You should "never" have a catch-all like this: neither "catch" by
itself nor "catch (Exception ex)".

Never say "never".

try
{
ModifyDB();
Commit();
}
catch
{
Rollbac();
throw;
}

Perhaps you don't consider this "catching" the exception since it is always
re-thrown?

Also, when processing a large list of items (e.g. reading millions of
records from a file) there are a myriad of things that can go wrong. Your
catch list would stretch for miles. However, you certainly don't want the
whole process to stop 90% of the way through because one record had an
error, do you? Log the exception, go on to the next item, deal with the
exception when the process has finished.

[Bruce Wood]

Ah, yes. Point taken. I hadn't considered the rollback case.

Squirreling away the exception and dealing with it later is another
valid reason to "catch all" exceptions. Point taken, again. :-)

[Javaman59]

Hi Benny,

try
{
// some code
}
catch // note - i am catching everything now
{
// do something
}

As others have pointed out, this is universally regarded as bad practice,
except in a small number of very specific situations. It is one of those
things, like "goto's" that you can just take on authority.

Still, I'll give you an real-world example of why...

Some months ago, in a test utility, I had to introduce an exception handler.
Because it was just test code, I decided to do a "quick and dirty", as in
your example..

try
{
// some code
}
catch
{
// do something
}

Last week, I shifted to Visual Studio 2005, and my test utility stopped
working. I *eventually* found the reason. My code had, all along, an
underlying thread flaw. .Net CLR 2.0 detects this flaw, and raises an
exception. The exception happened to be caught in the catch-all, and the
symptoms of the problem arose later. If i didn't have the catch all, then the
exception would have gone straight to top, and halted the program
immediately, with a meaningful diagnostic.

My "quick and dirty" in the test utility ended up costing me some time. If
it had been complex production code, which I had inherited from someone else,
it could have been more serious, and could have cost a *lot* more time.

Regards,

Javaman

[Phillip Trelford]

Hi Benny,

You can implement the IsInteger routine without try/catch in .Net 1.1 using
the double.TryParse static method that has already been mentioned. It has a
parameter NumberStyles which you call with Integer, and is equivalent in
result to your previous method.

public static bool IsInteger(strin g s)
{
double result;
return double.TryParse (s, System.Globaliz ation.NumberSty les.Integer, null,
out result);
}

Its a bit cryptic though that you have to use a method of double.

Hope this helps.

Regards,
Phil

"Benny" wrote:

Hi,

I have something like this:

try
{
// some code
}
catch // note - i am catching everything now
{
// do something
}

Will this sort of catch statement, catch 'unsafe' and 'kernal-level'
exceptions (even if the app is a simple asp.net app with no unsafe stuff)?
(just wanted to confirm as I had a debate with one of my friends - AFAIK i
feel it doesn't since no unsafe code is used and since Win32 exceptions are
mapped into managed .NET exception classes)
Also, in many cases, i have catch blocks which does nothing - because i
don't want any exception to be propagated...so mething like follows.

public bool IsInteger(strin g val)
{
bool result;

try
{
int.Parse(val);
result = true;
}
catch
{
result = false;
}
return result;
}

Is this OK (a good practice)?

Thanks,
Benny