clarification on exception catching

[Dave Karetnyk]

I guess this might be a more general question but I first saw it in context of some data grid code... I had the following executing within the context of a GridSelectionChanged event:
t[i] = Image.FromFile((string)dr[i]["ThumbRef"]);

An entry in the xml file was wrong giving a FileNetFoundException in one instance. For now I have no exception handling locally within my method processing the selection changed events. What happens then is that the application just continues to run, in spite of the exception!

Strategy for the application is to handle exceptions as appropriate, and in scenarios where something 'fatal' happens we have exception handlers at the 'top level' which catch the exception, write it to the event viewer, then exit the application. This is done by setting up exception handlers for the main ui thread and the other threads (pool, garbage, managed) in a manner described by, e.g., John Robbins (http://www.wintellect.com/resources/newsletters/articles/appsdie.aspx)

I can get fatal exceptions to our top level handlers (one above is just by way of example) by setting the PassThroughExceptions property of the Syncfusion ExceptionManager to true. At least I do now see the above file not found exception.

Ok, but now I have some general questions in my head:
1) The ExceptionManager docs state "All static settings for this class are thread local". I'm calling it on the main ui thread. But what about the other threads? Or do I not need to bother with them?
2) Setting this property to true only makes sense if there is no side effect of now seeing exceptions that I'm not interested in! I'm guessing this will not be a problem but it is only a guess... For instance, maybe you guys have to work around some problems within the base Microsoft assemblies by catching exceptions?

What do you think?

Regards, Dave.

[Administrator]

Hi Dave,

if things go as usual there should be no excpetions at all within the grid. There are also no workarounds that come to my mind about catching exceptions for problems with Microsoft assemblies.

However, there is one type of exception that we always catch within the grid, and that is when a string gets converted to a cell value or vice versa. Also, when we do validate cell contents it is not unusual that a exception is thrown and the grid has to handle it. Also, when data are saved back to a datasource and constraints are violated exceptions might occur.

The grid will handle conversion exceptions independent of the ExceptionManager setting you specified since it is not practical to let them bubble up. That's why exceptions that are thrown while in DrawCell or SaveCell will usually not bubble up.

All other exceptions should honor the ExceptionManager setting and will bubble up based on this setting.

Grid operations should in general occur on the GUI thread. So, in 98% of the cases setting the ExceptionManager property for the GUI thread only should be just fine.

However, if there operations happening on another thread and grid code is involved that handles exceptions, then you will have to set this property for every single thread. You could do this at the start of the method where you think a exception could occur. That way you can be sure the property is set on the right thread.

Stefan