Is "throw new Exception(...)" a good practice?

[Patrick]

Hi,

It seems that "throw new Expcetion(...)" (in C#) is not a good
practice because the exception is too generic to catch without ignoring
some low level exceptions such as OutOfMemoryException and
StackOverflowException. For me, I cannot figure out any advantage to
throw Exception directly except forcing the client to use "catch
(Exception ex)" or to prevent this exception from throwing by checking
some conditions.

For example, System.Drawing.Graphics.FromImage(Image image) will
throw Exception if the specified image is an image of indexed pixels. I
know I can check (image.PixelFormat & PixelFormat.Indexed) before
calling FromImage() to prevent this problem. However, in other cases,
there may not be any condition I can check in advance before the
Exception is thrown.

Hence, here are my questions: Is "throw new Exception(...)" a good
practice? If not, why do Microsoft programmers implement it in this
way?

Patrick

 

[TOM]

throw new Exception is I think designed if you need to throw an exception
different from one that you caught. If you are attempting to re-throw the
existing exception, you will erase tracks previous to your new exception,
making it more difficult to trace what is happening

If you want to re-throw an existing exception, just throw. The original
exception
will then be able to be traced.

See http://www.codeproject.net and search for the several recent
articles
on best exception handling practices.

-- Tom

 

[Patrick]

Hi, Tom,

Thank for the reply. However, I am asking "Is it good to throw
System.Exception instead of other types derived from
System.Exception?". Sorry for the confusion.

Patrick

 

[Alvin Bruney [ASP.NET MVP]]

One reason you can do so is if you happen to catch an unrecoverable
exception. So in that case, you log what you have to, perform some cleanup
code and re-throw or just throw a system exception to terminate the
application.
This situation isn't common and I would only expect to see it in
applications that must make certain guarantees about run-time integrity.
--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
_________________________

 

[Scott M.]

I can see the use of it when handling the specific exception in the back-end
tier and wanting to throw a different type to the UI tier. The original
exception could be logged in the catch and the new exception could then be
sent to the UI layer.

 

[Luc E. Mistiaen]

throw new Exception is I think designed if you need to throw an exception
different from one that you caught. If you are attempting to re-throw the
existing exception, you will erase tracks previous to your new exception,
making it more difficult to trace what is happening

Not at all: if you do the following

catch (Exception e)
{
throw new Exception ("My grain of salt", e) ;
}

you add your own information and keep all the stack of the lower level
exceptions. So you can just enrich the lower level exception with
information pertaining to the exact condition under which it occurs in your
code.

/LM

 

[David Levine]

There really isn't any consensus on this; for every good reason not to throw
Exception there are other reasons for doing so. I don't like defining custom
exception classes just to throw something other then Exception - unless
there's some specific, programmatic recovery that can be done based on a
specific exception type there's little to recommend it.

Unless there's some reason not to throw an exception of the same type
(perhaps some operations are security sensitive) I find myself doing this...

catch(Exception ex)
{
// if cannot recover then...
throw CloneException("Add some context info.",ex);
}

The method CloneException creates a new exception object of the same type as
the original (if possible), and it wraps the original exception in the
InnerException field of the new exception.

If the code is creating and throwing a brand new exception then I generally
try to use an existing exception class, such as ArgumentOutOfRangeException,
etc.

IMO this is an area that still needs lots of thought, research, and work.