ramsenthil18 / elmah

Automatically exported from code.google.com/p/elmah
Apache License 2.0
0 stars 0 forks source link

Allow logging of events other than exceptions #263

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I would like to log messages for events which are not exceptions.  
i.e.  "Task Started", "Admin user logged in", "150 records exist", etc...

Some messages other than exceptions can provide important information to a 
system log.  I know I could raise an ApplicationException but this would convey 
meaning I don't intend.

Original issue reported on code.google.com by keith9...@gmail.com on 12 Dec 2011 at 5:21

GoogleCodeExporter commented 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

GoogleCodeExporter commented 8 years ago
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