Wow guys thanks for all the answers and advice! I guess I found out where
all the smart people hang out ;).
I'm new to .Net exceptions and still trying to wrap my head around some
parts of it.
Yes, CustomException derives from Exception. I used the example of display
strings, but really I want to update an CustomException.ExceptionID property
that is defined as a GUID. I subsequently pass the exception to the
Enterprise Library (EL) Exception Handling Application Block, which logs the
exception including all its properties.
A little more background: this is a three-tier database application. I'm
trapping serious database exceptions in the Data Access Layer, wrapping them
in one of my CustomExceptions, logging them (via the EL), then re-throwing
them. (In the case of security exceptions, they are not re-thrown, but
rather a new dumbed-down exception is created and thrown.)
Eventually there will be various exception handlers in the business and
client tiers. However, for starters I am writing the "last chance" handler
in the global.asax Application_Error block. Without this, the full exception
is displayed to the user in the browser.
In the Application_Error block, I'll create a new CustomException and use
the EL to log it, then display a simplified message in the browser.
If the exception that I'm handling in the Application_Error block is one of
my custom exceptions, I want to use the ExceptionID from that
CustomException in the new exception. That way, potentially multiple
exceptions in the event log(s) can be identified as having the same cause.
However, exceptions percolating up to the Application_Error block are also
quite likely to be standard but unpredictable system exceptions (file locked
by another process, disk full, etc.). Those will also be wrapped and logged,
but they'll get a System.Guid.NewGuid() in their
CustomException.ExceptionID.
So that's the long answer of why I need to know if the "exc" I get is a
CustomException or not. My understanding is that using "is" or "as" is
unavoidable in this case?
NOW, this brings up another question: what if I decide that I need to do
different things for different types of exceptions, whether they are system
exceptions or derived from CustomException? For example, some exceptions may
not be fatal, so I can call Server.ClearError() and allow the user to
continue. However, others may mean I need to clean up and shut down. How
would I differentiate the different types of exceptions if not using "is" or
"as"? Or is it possible/advisable to use try - catch inside the
Application_Error block?
Thanks again for the helpful discussion,
Mark
"Mark Wilden" <mw*****@communitymtm.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...
"Mark Berry" <ma***@sorrynoemail.comwrote in message
news:u5**************@TK2MSFTNGP04.phx.gbl...
>My specific example is that I have a CustomError class with several
specific error types that derive from it (CustomBuinessError,
CustomTechnicalError, etc.). The CustomError base class has some extra
fields that I want to log or display when an error is handled.
Don't use "is" or "as." Don't require the clients of an object to know
which specific class it belongs to.
Instead, use polymorphism. Create a virtual method that in the base class
which the derived classes override to do the "extra" stuff. In this case,
define one or more virtual methods like GetLogString() or
GetDisplayString().
When your clients need to know what specific class they're working with,
you end up with maintenance problems when you add a new derived class. You
have to search your entire codebase for all the logic that's conditional
upon the results of "is" or "as." By using polymorphism, you keep all the
differences in one place - in the class that's defining the differences.
"is" and "as" should be avoided wherever possible in favor of
polymorphism. Sometimes they're necessary, but it doesn't seem like this
is one of those times.
///ark