What Exceptions to catch

[Steven Blair]

Hi,

I need to catch exceotions on File.Delete()

After checking the help, I have noticed that thgere are serevral
Exceptions that can be thrown.
My question is, should I catch all thes Exceptions, or if I simply do
the following:

try
{

}

catch(Exception e)
{
e.Message; //do something useful with this
}

Will this catch all the Exceptions that a File.Delete can throw ?

Regards,

Steven

 

[Erik Tamminga]

Hi,

If all you're doing insinde try {} catch is File.Delete, do a
"catch(exception e)", this will capture all events that could be raised.
System.Exception is the mother of all exceptions and will thus catch all
possible exceptions.

Erik

 

[Teemu Keiski]

Hi,

http://msdn.microsoft.com/library/d...ef/html/frlrfSystemIOFileClassDeleteTopic.asp

here are listed all the exceptions it can raise. Sure, with Exception you
can catch them all, but if you need to do specific processing based on
exception type, having more than one catch clause is an option.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi steven,

Will this catch all the Exceptions that a File.Delete can throw ?

It will do that, if all you need to know is if was a problem deleting the
file that's the way to go, if you need to do different things depending of
why it fails you should catch the particular exception, in this case you can
declare for example two catch one for the exception that you are interested
in and other for Exception to catch all the others.


Cheers,

 

[Steven Blair]

Ok thanks,

Thats definately made things a bit clearer for me now

 

[William Ryan eMVP]

Steven:

I would highly recommend against catching System.Exception except in very
rare situations. Exception handling isn't meant to simply keep the app
from crashing, it's purpose is to allow you to respond to predictable
problems in a structured method. For instance, if you attempt to open a DB
connection, the server could be down, network cable unplugged etc. None of
which is the fault of your code. As such, you would probably want to catch
a SqlException for instance and respond in a special way .

I see Ignacio posted the possible exceptions, but trap precisely. If you
use System.Exception, and an OutOfMemoryException is raised, it'll be
caught. If you catch System.Exception you could easily hide problems and
introduce logic errors which are very very bad.

HTH,

Bill

 

[Rahul Anand]

There should be a proper Hierarchy in Exception handling.
All the Exceptions which can occur due to a statement or block of code
should be handled first, after catching and handling all such
predicted exceptions, we should go higher in hierarchy to catch
unpredicted exceptions.

Unpredicted exceptions should also be handled for logging and
debugging purposes.

Also note there is difference between a bare catch and catch(Exception
e) statements.

catch(Exception e) will catch only those exceptions defined under
System whereas a bare catch will catch all exceptions (might be
generated in some com component for example).

Hope it will help.

 

[Dave]

There should be a proper Hierarchy in Exception handling.
All the Exceptions which can occur due to a statement or block of code
should be handled first, after catching and handling all such
predicted exceptions, we should go higher in hierarchy to catch
unpredicted exceptions.

Unpredicted exceptions should also be handled for logging and
debugging purposes.

Also note there is difference between a bare catch and catch(Exception
e) statements.

catch(Exception e) will catch only those exceptions defined under
System whereas a bare catch will catch all exceptions (might be
generated in some com component for example).

Hope it will help.

To be precise, using a bare catch will catch non-cls compliant exceptions
(exceptions which do not derive from System.Exception, such as integers
instead of objects), and using catch(System.Exception) will catch all
cls-compliant exceptions. From what I've read if you write CLS compliant
code then you should never get a non-cls compliant exception - even COM and
win32 exceptions are translated into cls compliant exceptions.

 

[cody]

To be precise, using a bare catch will catch non-cls compliant exceptions

(exceptions which do not derive from System.Exception, such as integers
instead of objects

I have always bee wondering how a C++ programm can determine which type an
Exception is.
An int does not support rtti so how can the system know? Even if the
Exception includes something
like a typeid, is is guaranteed to be the same on all compilers? Then
somewhere must all typeid's of the primitive types be defined.

 

[Dave]

I have always bee wondering how a C++ programm can determine which type an
Exception is.

Hmmm., it's been so long since I've written anything in C++.....

As I recall, there was a way to map 32 bit exception codes into C++ types.
Use the method _set_se_translator to tell the runtime to call your mapping
method when an exception occurs. I used to use this but its been years, so
my memory has definitely faded. But you have to do the work yourself.

Anyway, I don't know of any .net app written in a high level language that
can even throw an exception that is not derived from System.Exception. There
may be something out there that does but it would definitely be an oddball.

An int does not support rtti so how can the system know? Even if the
Exception includes something
like a typeid, is is guaranteed to be the same on all compilers? Then
somewhere must all typeid's of the primitive types be defined.

I think you're thinking of this in MFC terms (rtti?). Come over to the dark
side, start coding in C#.....

Anyway, if all you have are untyped exceptions (win32 seh) then your code
has to look at the actual exception code and try to figure out from that
what it means. (e.g. 0xC0000005 == ACCESS VIOLATION, also known as a null
pointer) There's a reason why .net does not use that model - it's damn hard
to use. C++ was better, but you typically had the worst of all worlds,
because some errors (e.g. COM) manifested themselves as sentinel return
values from methods (for which there is no standard return value to signal a
failure), some errors where thrown as C++ types, others as untyped win32 SEH
exceptions, some methods used SetLastError(), etc.

..NET exception handling unifies the error handling model - one size catches
all. Unless someone insists on writing code that uses one of the other means
of reporting error conditions.

 

[cody]

Anyway, I don't know of any .net app written in a high level language that

can even throw an exception that is not derived from System.Exception. There
may be something out there that does but it would definitely be an

oddball.

If you write directly in MSIL, all native code or use a third party .NET
language then this can certainly occur.

I think you're thinking of this in MFC terms (rtti?). Come over to the dark
side, start coding in C#.....

If thought dynamic type information is a feature of C++, not MFC. maybe C++
uses another name for this Iam not sure.

 

[Dave]

oddball.

If you write directly in MSIL, all native code or use a third party .NET
language then this can certainly occur.

My reference on the IL instruction set is that the throw statement will pop
the instruction reference from the stack and throw it as a managed
exception. I suppose it could be a reference to an integer. Is the resulting
code verifiable? It would definitely be odd (to me anyway). C# and VB are
not supposed to do that Do you know of a high level language that does?

Even with unmanaged code the runtime maps exceptions to managed exception
types (SEHException and COMException). I expected this to cover all native
code but perhaps this is an incorrect assumption on my part.

If thought dynamic type information is a feature of C++, not MFC. maybe C++
uses another name for this Iam not sure.

If seen the term rtti used with MFC but not with C++. But as I said, it's
been a long time since I wrote C++ code. Anyway, native SEH does not throw
exception types, only exception codes. C++ needs to translate a code into a
type.