Assign diff. EventId for each EventLog using Exception Hanling Application Block

Topics: Exception Handling Application Block, Logging Application Block
Nov 14, 2007 at 10:17 AM
Hi ,

Im using Exception Hanling Application Block
How to give diff. EventId for EventLogs which were generated by using Exception Hanling Application Block.

i.e, at the time of configuration i was given eventId="100". So when ever an exception occur its giving the same eventId="100" for all the event logs.

<exceptionHandlers>
<add logCategory="EventLog" eventId="100" ... name="Logging Handler" />
</exceptionHandlers>

Plz tell me how to give diff. EventId for each EventLog?

Thanks in Advance,
Veera
Nov 14, 2007 at 11:13 AM
Hi Veera,

You want different event ids depending on what? If it depends on the type of handled exception, you could set up a fine grained policy and assign a different logging handler for each of the exception types...

Fernando
Nov 14, 2007 at 11:35 AM


fsimonazzi wrote:
Hi Veera,

You want different event ids depending on what? If it depends on the type of handled exception, you could set up a fine grained policy and assign a different logging handler for each of the exception types...

Fernando



Hi Fernando,

Thanks for the response...
Im Logging exceptions not based on exception types... but i want to give unique Id for each exception logged the event log

catch (Exception ex)
{
bool rethrow = ExceptionPolicy.HandleException(ex, "SME Exception Policy");
if (rethrow)
{
throw;
}
}


Nov 14, 2007 at 11:59 AM
Hi,

You mean want a new, never used before id each time you log? There's no support for that, and for a reason; besides being hard to implement (think app restarts, different log destinations, etc) it's not really the appropriate way to use event Ids. What do you need these unique ids for?

Event Ids are more about the type of event than a unique key for an event instance, if that's what you're looking for. However, if you still want to implement this feature you can create your own logging trace listener or change the existing one.

Fernando
Nov 15, 2007 at 8:54 PM
I have this request as well. I've seen it used to tag things like stored procedures or such, allows filtering the events to be easier. It might be a static value in his code, but perhaps he wants to tag a whole bunch of things. The way I've done this in the past is to use the exceptionutility class to format the exception to then drop it into the logger (where you can override the eventid)
Nov 15, 2007 at 9:26 PM
string policyName = "Handled Exception";
string logMessage =
errorTitle +
Environment.NewLine + Environment.NewLine +
ExceptionUtility.FormatExceptionHandlingExceptionMessage(policyName, null, null, ex);
Microsoft.Practices.EnterpriseLibrary.Logging.Logger.Write(
logMessage, "General", 4, errorNumber,
System.Diagnostics.TraceEventType.Error,title, info);

Here is some code that I use, it is convenient because I like to have the offending method and error at the top of the event log as well, so this gives me the flexibility to do that. However, I am unaware of how to actually get the policy settings ("General, 4, etc injected above statically), whereas actually using the exceptionpolicy for the exception puts that all in there automatically. For this though, it's not a big deal, since all of my sql errors use the above, i know they're of the same type information.

I like to have the data access methods each tagged with a different EventID. I saw it used in my prior company, and sort of found it interesting and useful.
Nov 16, 2007 at 2:02 PM
Hi,


kidzi wrote:
I have this request as well. I've seen it used to tag things like stored procedures or such, allows filtering the events to be easier. It might be a static value in his code, but perhaps he wants to tag a whole bunch of things. The way I've done this in the past is to use the exceptionutility class to format the exception to then drop it into the logger (where you can override the eventid)


I don't think you're requesting the same thing, but we haven't heard back from the original poster. As far as I can tell, you're asking for fine grained control on the event id (your 'tags') to easy filtering, while he is asking for a unique ID. Neither one is supported.

My understanding of the initial post was the same as your request, so I'll ask you the same question: how would the event id be determined based on the exception? Ie, where would the errorNumber in your sample come from? Keep in mind this logic is something you'll have to express through configuration, or be something you supply through context information (similar to activity ids).

Fernando
Nov 16, 2007 at 3:21 PM
The number would be tagged to the SP, so it would just be a constant for that DAL function. There is no 'determination'. It is in there, and there would be an external operations document (unless there is some system to store it) which would have the IDs, where they are, what method they represent, and maybe any mitigation or other ancillary information.

Then when the eventlogs are checked, the eventid will be fairly fine grained and you can of course look in the data, but if you're on a production system with numerous things going on, it helps with filtering and determing how often something occurs.

I wouldn't make it dynamic, that wouldn't make sense to me either. The point with using the manual logging apis like i have above is so you do not have to use a particular eventid hardwired in the configuration.
Nov 16, 2007 at 3:39 PM
Let me rephrase my question.

There's an exception, and you're using the EHAB. At some point, an exception handler will be given the chance to act, and it will issue a logging request with an event id that it needs to determine (or calculate, or figure out) based on the information available to it which consists of the exception, its own configuration and any context information that has been previously configured (usually through TLS). How would this tag in your SP be used by this exception handler? What do you mean by "it is in there"?

I understand the usefulness for this feature; I'm merely asking how you expect the feature to work. Take a look at Tom Hollander's for a related implementation http://blogs.msdn.com/tomholl/archive/2007/08/01/mapping-sql-server-errors-to-net-exceptions-the-fun-way.aspx; while neither logging nor event ids are used, context information (eg the sql error code in the exception) is used to determine the result (ie the kind of exception to create) based on configuration.

I hope the question is clearer now.

Regards,
Fernando