Exception emailing

Exception emailing

Old forum URL: forums.lhotka.net/forums/t/4096.aspx


ajj3085 posted on Friday, December 28, 2007

Hi,

I recently switched to a three tier setup.  Previously, the client would catch any unhandled exceptions and show a generic error box, as well as email me the exception details.  Now, if an exception occurs on the application server, I get an email which simply states that the byte stream is not in the expected format.  Not so helpful.

My original idea is to override DataPortal_OnDataPortalException and just email there.  This works, but sometimes exceptions are raised because of an event in the database, which I handle by displaying a custom message to the user.  For example, if someone saves an invoice, and another user has edited the invoice an attempts to save, I raise an error in the stored procedure, which the BO will catch and rethrown as a custom exception.  The UI catches this and displays the appropriate message.

The problem is that in that case I am now getting emails for these "routine" exceptions.  I'm hoping there's a way to weed these out.. any ideas?

Thanks
Andy

tmg4340 replied on Friday, December 28, 2007

I'm assuming that you don't want to take your concurrency checks and move them out of your SP's - because if you did that, you could simply throw a custom exception and catch that appropriately.  But you knew that.  Smile [:)]

About the only thing I can think of is some parsing of the exception message.  It's a little funky, but it's about all I can think of to do.  If you're using VB.NET, you could add "When" clauses to your Catch statements.  Those could examine the text of the SqlException you're catching, and as long as you provide appropriately-constructed error text in your SP's, it would work.  If you're using C#, then you'll have to code that on your own, using a series of if/switch blocks within your "catch" blocks.

Another option would be checking the "Number" property of the SqlException - I think if you provide an error number in your RAISERROR call, that ends up in the "Number" property.  It's just a different form of parsing, but parsing by numbers feels a little better than string parsing (and it would be faster, too).  But it's the same basic concept.

HTH

- Scott

ajj3085 replied on Friday, December 28, 2007

Well, if i move the check out, then its possible that I blow away someone else's changes.. so that's not an option. Smile [:)]

Hmm... those parsing ideas aren't bad.  I'll have to check out the number; i know there are some parts of the raiserror that are for user use.. so anything like system assigned should be bubbled.

Thanks!
Andy

tmg4340 replied on Friday, December 28, 2007

I know that RAISERROR requires that any error # you provide has to be over 50,000, and if you don't specify a number, it will default to 50,000.  However, the kicker to using a message ID is that it's essentially considered a user-defined system message, which means you'd have to add it to the "sys.messages" catalog view using the "sp_addmessage" system SP.  Don't know whether you want to go through that kind of effort.  If you provide message text instead, the error # is always 5000.

(While this is a little confusing in relation to the earlier statement (at least it was to me), I believe that what this means is that if you provide some error text, the error # is 5000.  If you provide an error number, it better be > 50,000, and it better match something in the "sys.messages" catalog view.  If you provide neither a number nor text, the error # is 50,000.)

I thought you might be able to use the "State" parameter of RAISERROR - there is a "State" property on the SqlException - but I can't tell from the docs whether those match up or not.  It's not exactly what you're supposed to use "State" for, but...

You'll probably end up having to do some testing to see what you can get from a RAISERROR.  You might be forced to use text parsing.  But look at it this way: you're planning on wrapping the error in a custom exception, so your exception text can be pretty much anything you want.

- Scott

Copyright (c) Marimer LLC