CODEWITHSUNDEEP
c#exception
alaasdk
alaasdk

Reputation: 1998

Fields to save in database when Handling C# Exceptions

I am going to handle a project to a client for a testing phase, the project build with ASP.NET MVC3 .. What I need is to save all exceptions occurs to a persistent location -SQL Database-

and I have some questions..

  1. what field should I save in the database? (Msg, trace, etc)
  2. I have seen people save the inner exception but sometimes my exceptions have null inner exception.
  3. What is the best place to handle the error and save to the DB. (In global.asax OR defining a custom error page in web.config and get the last error with server.getLastError)

Upvotes: 1

Views: 2220

Answers (2)

Dmitry Reznik
Dmitry Reznik

Reputation: 6862

  1. As Jon Skeet said, the more fields you save the more data you will have to diagnose the problems as you go. Personally, I'd go for serializing the exception and putting it in the "XML" type column if you have the ability to do so (database space and performance considerations). This would also eliminate the second problems since the inner exception will be serialized also. Though with this approach all your custom exceptions should be able to serialize themselves correctly.
  2. I'd recommend looking at freely available source codes for error loggers such as Elmah to get the basic idea.

Upvotes: 1

Jon Skeet
Jon Skeet

Reputation: 1500425

what field should I save in the database? (Msg, trace, etc)

Everything you can, if possible:

  • Type
  • Message
  • Stack trace

I have seen people save the inner exception but sometimes my exceptions have null inner exception.

And some will have more than one, nested. You should save everything you can, IMO. How you structure that is up to you, but you could always add the innermost one, then the containining one with a foreign key to the innermost one, etc, working your way outwards.

What is the best place to handle the error and save to the DB.

Can't help you on that part, I'm afraid. You may want to consider doing this asynchronously though, queuing them up. This is particularly relevant when the exception may itself be a database error - if you can build up a queue (with a maximum size, of course) so that once any database problems have been restored, the errors can then be stored, that could be useful. Or potentially dump them to disk first, and periodically upload that log to the database.

Upvotes: 4

Related Questions