Closed GoogleCodeExporter closed 8 years ago
Hi there!
Firstly let's look at a WORKAROUND that requires no change to ELMAH:
1) Bear in mind that ELMAH has been written to log *unhandled/unexpected*
exceptions.
2) Various other logging frameworks exist for when you know that things are
occurring in your application
3) Remember that you can signal exceptions to ELMAH using ErrorSignal.Raise
As you say, raising an ApplicationException would convey meaning you don't
intend.
However, doesn't logging a message (as opposed to an exception) in a repository
for unhandled exceptions also conveys meaning that isn't intended!
4) So rather than raise an ApplicationException, you could create new Exception
classes along the lines of:
a) DebugMessageException
b) InformationMessageException
c) WarningMessageException
d) TaskMessageException
e) SecurityMessageException
You could wrap your messages in these new exceptions and convey some of the
meaning you intend without requiring a major change to ELMAH.
Secondly, let's look at the possibility of changing ELMAH.
To truly meet requirements, we would need to be able to distinguish between:
a) unhandled exceptions
b) handled but logged exceptions
c) messages - and in here we would need to be able to distinguish between the
types of messages
Can you propose how you expect such a feature to work in terms of UI and API?
Or perhaps the workaround above already provides much if not all you require!!
Regards,
James
Original comment by jamesdriscoll71
on 13 Dec 2011 at 11:19
This risks leading to feature creep. You may wish to star other issues, like
issue #53 or issue #162, that could enable the same benefits by allowing
additional contextual information to be coupled with an error.
Original comment by azizatif
on 27 Feb 2012 at 8:51
Original issue reported on code.google.com by
keith9...@gmail.com
on 12 Dec 2011 at 5:21