How to handle non-serializable exceptions in general way?

How to handle non-serializable exceptions in general way?

Old forum URL:

rsbaker0 posted on Wednesday, December 28, 2011

I have a case where we are using a third-pary component server-side that throws non-serializable exceptions -- none of the custom exceptions implemented by this component are serializable. I did some searching and found Andy's suggestion to overrride DataPortal_OnDataPortalException() here:

However, I'm having a little trouble understanding how that would work. In the version of CSLA I am using (3.5), the SimpleDataPortal seems to unconditionally rethrow the original exception and ignore anything that happens while invoking DataPortal_OnDataPortalException, so I can't see how to "replace" the original exception with one that is serializable without modifying the SimpleDataPortal implementation.

JonnyBee replied on Wednesday, December 28, 2011

Yes, that is hard to create in 3.x.

One option is to have your own exception handling in the data access code - catch the non-serializable exceptions and rethrow a new serializable one. .

In 4.0 and onwards you have the IDataPortalExceptionInspector and the Samples\Net\Cs\CustomeErrorHandling shows how to plug into the DataPortal pipeline and log and/or transform the  non-serializable  exception.

You should be able to downport til to Csla 3.5 or create your own alternative mplementation.

rsbaker0 replied on Wednesday, December 28, 2011

OK, thanks. I've been backporting selected features for a while as needed so that may be a good approach here.

rsbaker0 replied on Thursday, December 29, 2011

OK, it was trivial to backport the IDataPortalExceptionInspector support back to 3.5, but the plot seems to thicken.

It seems like you can't really test an Exception for serialization very well.  I'm considering just trying to serialize it directly and catching the exception as a method of determing whether it is truly serializable. Is there a better (less expensive?) way?

JonnyBee replied on Thursday, December 29, 2011

I made the simple assumption to check if the Exception class (and inner exceptions) had Serializable attributte. 

The safe and expensive alternative is to serialize the Exception graph and catch serilization exception. 

RockfordLhotka replied on Thursday, December 29, 2011

You can also look at the Silverlight data portal, because no exceptions are serializable in that case. So we always serialize server exceptions. You might find the existing data structure and code to copy the exception data to be useful.

rsbaker0 replied on Thursday, December 29, 2011

Those are both good ideas. I was lamenting the loss of detail (particularly the stack trace) when replacing the unserializable exception, so any solution that might let me capture more information will be an improvement.


Copyright (c) Marimer LLC