Patch for /src/Elmah/Error.cs

[GoogleCodeExporter]

Add try-catch around the constructor code that accesses context.Request, 
because it's possible for Request to be invalid and throw an HttpException even 
when context isn't null.  This change should allow developers to use 
ErrorSignal.Raise() for error handling outside of normal HTTP requests, e.g. 
during Application_Start or asynchronous processing.

Original issue reported on code.google.com by pkar...@gmail.com on 4 Mar 2012 at 5:24

Attachments:

• Error.cs.patch

[GoogleCodeExporter]

Thanks. Could you described the asynchronous processing case in a bit more 
detail?

Original comment by azizatif on 4 Mar 2012 at 9:14

[GoogleCodeExporter]

Sure, although Application_Start is our primary use case, as we just recently 
had two bad commits that brought down our testing environment due to errors 
during startup.  (We're simultaneously working on making our startup code more 
robust and testable.)

One thing we do asynchronously is log performance statistics about each request 
into a database.  We've had problems in the past handling errors within that 
code, and I believe right now errors are just getting ignored.  I'd like to be 
able to use ELMAH to log the errors and send us an email alert.

Original comment by pkar...@gmail.com on 4 Mar 2012 at 11:03

[GoogleCodeExporter]

Thanks for expanding. ErrorSignal is designed to be used during the processing 
of an HTTP transaction, including asynchronous processing such as through async 
handlers and pages. If you are attempting to use it outside of that scenario 
then I'm afraid you cannot rely on ErrorSignal. You will have to log exceptions 
directly to the ErrorLog for such cases. For example, if you try to signal an 
exception during Application_Start, you'll find that it will fail because there 
won't be any application instance available for signaling to even begin and it 
won't even reach the creation of the Error object. However, logging directly 
via ErrorLog.Log will still work.

Original comment by azizatif on 6 Mar 2012 at 5:58

• Changed state: WontFix
• Added labels: Component-Logic

[GoogleCodeExporter]

I agree that ErrorLog.Log() still works outside of an HTTP transaction, and 
exceptions are correctly added to our ELMAH database when we use it.  What I'm 
looking for is a way to trigger ELMAH's email logic (i.e. not just the logging 
logic) outside of an HTTP transaction.  With the proposed patch in place (and 
Elmah.dll rebuilt locally) I have gotten to and past the creation of the Error 
object.

Original comment by pkar...@gmail.com on 6 Mar 2012 at 6:46