Exception

[Guest]

Hi :
I wanna know how many kinds of exceptions are there exist in CSharp?I
dont wanna always write codes like following
/////////////////
try
{}
catch(Exception e)
{
}
/////////////////
I wanna get the accurate excepiton info.

 

[Carl Daniel [VC++ MVP]]

Hi :
I wanna know how many kinds of exceptions are there exist in
CSharp?I dont wanna always write codes like following
/////////////////
try
{}
catch(Exception e)
{
}
/////////////////
I wanna get the accurate excepiton info.

The set of exception types is unbounded, since any assembly can define as
many new exception types as it wants.

There are a number of high-level exception types (e.g. ApplicaitonException)
that are intended to serve as intermediate base classes for user defined
exception types. Frequently, catching one of those intermediate types will
enable you to more appropriately handle some errors (and not handle others).

Note that you can always use the object.GetType() method on any exception
objec to find out it's complete type. You can also is the C# 'is' and 'as'
operators to try discover the exception's type as well.

Generally though you don't want to be handling lots of different types of
exceptions in different ways - if you find yourself writing code that needs
to catch a high level exception and then inspect it to determine whether
it's some particlar sub-type, odds are good that there's another way of
accomplishing the same thing without the runtime type inspection.

-cd

 

[Peter Duniho]

Hi :
I wanna know how many kinds of exceptions are there exist in CSharp?I
dont wanna always write codes like following
/////////////////
try
{}
catch(Exception e)
{
}
/////////////////
I wanna get the accurate excepiton info.

There was a fellow over in the m.p.dotnet.framework newsgroup that
wanted the same thing. Here's what he came up with:

http://eldora-software.com/blogs/ListofNETexceptions.htm

More generally, you could just start at the MSDN page for the Exception
class, and follow the links from the class hierarchy to the various
derived classes.

Finally, note that MSDN attempts to document all exceptions that a
method call might throw. So generally speaking, you could just look at
the documentation page for the .NET API you're using and handle the
specific exceptions that you can do something useful with.

Pete

 

[Guest]

There was a fellow over in the m.p.dotnet.framework newsgroup that
wanted the same thing. Here's what he came up with:

http://eldora-software.com/blogs/ListofNETexceptions.htm

More generally, you could just start at the MSDN page for the Exception
class, and follow the links from the class hierarchy to the various
derived classes.

Finally, note that MSDN attempts to document all exceptions that a
method call might throw. So generally speaking, you could just look at
the documentation page for the .NET API you're using and handle the
specific exceptions that you can do something useful with.

Pete

Thank you Pete, that is just it.

 

[DaveP]

my concept about the try catch:
i have several services that use only 2 Try/Catch Blocks

one is at the Service level
the 2nd is at he service code (job classes)
this is at the top classs run Method
so all lower code if a error happens it finds its way in the
top error handler (try/catch) where i make decisions about the error log to
1=sql server or 2 log to text file and finally log to event log
there are places where i want to catch errors and return a value instead of
throwing another error for example

dvfileinfo.FileOpen(sFilename)
i have a Try/Catch block in this and i return a null file stream or a
FileStream...the try catch block is at the
try
{
fs=new FileStream(sfilename, mode,access,sharing);
}
catch(exception e)
{
fs=null;
}
return fs;

a user can choose to use this instead of doing all the filestream things
you have to do in a ton of places
i have several constructors to handle fileinfo, sfilename,
show errors , etc
you just decide where the try/catch should be handling code

it all depends on ur needs and where you are codeing and what you are
coding, in most cases i like the errors
to be thrown all the way to the top of the Application

hope this helps a bit
DaveP