All,

I have some general purpose classes that I use that are stand-along DLL's and non visual components, such as my SqlDataAccess
class.

In this class I have an exception property that is defaulted to null. If an exception occurs, I store the exception to the property. Then it's up to the process that instantiated my SqlDataAccess class to continually check to see if the property is no longer null:

SqlDataAccess data = new SqlDataAccess()
data.ConnectionString = MyConnString;

SqlDataReader rdr = data.ExecuteReader(ProcName, colParams, CommandType.StoredProcedure);  

if(data.Exception != null)
{
    // Use the reader here
}
else
{ 
    // App.HandleException(data.Exception);
}

This if() might not be necessary of the class raised an event when an exception occurs.

I dunno, what do you guys think?






>>Anyone see anything wrong with create an event to raise when an exception occurs?
>
>Yes. This sounds like you try to implement VFP's error event. Exception handling and error event are contrary concepts that don't go very well together.
>
>An exception that isn't handled in your code should be passed on the calling hierarchy. I think this becomes obvious if you don't look at the simple scenario of A calling B, but A calling B calling C. If component C has an ExceptionOccured event, suddenly A and B have to subscribe to the event of component C. That means A suddenly needs to know about implementation details and calling hierarchies in component B. Or, component B would need another event that A subscribes too which passes on the exception. That would merely simulate exception handling but require a lot of code and makes it easy to break the chain accidentally.