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.
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.
OK, thanks. I've been backporting selected features for a while as needed so that may be a good approach here.
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?
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.
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.
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