views:

189

answers:

3

I am currently writing a winforms application (C#).

I am making use of the Enterprise Library Exception Handling Block, following a fairly standard approach from what I can see. IE : In the Main method of Program.cs I have wired up event handler to Application.ThreadException event etc.

This approach works well and handles the applications exceptional circumstances.

In one of my business objects I throw various exceptions in the Set accessor of one of the objects properties

set {

   if (value > MaximumTrim)
    throw new CustomExceptions.InvalidTrimValue("The value of the minimum trim...");

   if (!availableSubMasterWidthSatisfiesAllPatterns(value))
        throw new CustomExceptions.InvalidTrimValue("Another message...");

   _minimumTrim = value;
}

My logic for this approach (without turning this into a 'when to throw exceptions' discussion) is simply that the business objects are responsible for checking business rule constraints and throwing an exception that can bubble up and be caught as required. It should be noted that in the UI of my application I do explictly check the values that the public property is being set to (and take action there displaying friendly dialog etc) but with throwing the exception I am also covering the situation where my business object may not be used by a UI eg : the Property is being set by another business object for example. Anyway I think you all get the idea.

My issue is that these exceptions are not being caught by the handler wired up to Application.ThreadException and I don't understand why.

From other reading I have done the Application.ThreadException event and it handler "... catches any exception that occurs on the main GUI thread". Are the exceptions being raised in my business object not in this thread? I have not created any new threads.

I can get the approach to work if I update the code as follows, explicity calling the event handler that is wired to Application.ThreadException. This is the approach outlined in Enterprise Library samples. However this approach requires me to wrap any exceptions thrown in a try catch, something I was trying to avoid by using a 'global' handler to start with.

try
{
    if (value > MaximumTrim)
        throw new CustomExceptions.InvalidTrimValue("The value of the minimum...");

    if (!availableSubMasterWidthSatisfiesAllPatterns(value))
        throw new CustomExceptions.InvalidTrimValue("Another message");

    _minimumTrim = value;
}
catch (Exception ex)
{
    Program.ThreadExceptionHandler.ProcessUnhandledException(ex);
}

I have also investigated using wiring a handler up to AppDomain.UnhandledException event but this does not catch the exceptions either.

I would be good if someone could explain to me why my exceptions are not being caught by my global exception handler in the first code sample. Is there another approach I am missing or am I stuck with wrapping code in try catch, shown above, as required?

+1  A: 

As a thought, try adding (fairly early on - i.e. at the start of Main):

Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);

That said - it seems to work fine for me with or without...

Marc Gravell
A: 

According to MSDN, Application.ThreadException will only be fired if the exception isn't handled. Maybe there is a catch somewhere up the callstack that is handling the exception?

Another option would be to try using AppDomain.UnhandledException instead. It is the same as Application.ThreadException, except it works for all exceptions in the same AppDomain.

Andy
A: 

If you try to use use Application.ThreadException or AppDomain.CurrentDomain.UnhandledException the Debugger will catch the exception!

To test these methods you have to start the appication without a debugger.

HumerGu