-Tracing, sometimes it's good to mark the actual place in code where the
exception came from. By re-throwing the exception the an additional line of
diagnostic information is added to the exception's stack trace...
- To make a more "user friendly" error message. If a raw SQL Server
exception bubbled up tot he GUI the user would probably not understand it.
To make a more friendly message I would create a new exception class, with
ApplicationException as a base, and then pass my "friendly" message and the
raw exception to the base class constructor... You could also do this if you
need to internationalize your friendly message; you can pass a string
resource as your message rather than the, probably english, original error
message...
- Also, suppose I want to add additional information to my exception such as
the actual text of a SQL query, or perhaps the user identity, or maybe the
datetime of the exception. I can do this by making a new exception class,
again descending from ApplicationException, making the new class
serializeable, and then adding the additional fields & properties that I need.
"ah****@gmail.com" wrote:
Hi all,
Why would one want to rethrow an exception? Doesn't that defeat the
purpose?
Best,
Andre