Exceptions crossing the app domain boundary.

Exceptions crossing the app domain boundary.

Old forum URL: forums.lhotka.net/forums/t/8171.aspx


markell posted on Wednesday, December 16, 2009

Dear ladies and sirs.

I have the following question. When an exception occurs on the server, it is embedded in a DataPortalException, which then crosses the app domain boundary to the client.

In our case, the exception may be of a type unknown to the client side. For example, NHibernate may throw an exception, but the client side does not have any NHibernate assemblies deployed to it.

One way to solve the issue would be to compile a stub of NHibernate (we build it from the sources) with just the exceptions in it, but this is a bad solution, because it cannot be applied to libraries for which we do not have the sources.

So, I hardly see any choice but to somehow intercept the exceptions at the point where they are wrapped with DataPortalException and apply some custom logic on them.

Is there a well defined way to achieve this? Because, I did not notice any extension points in the server DataPortal type to plug in custom logic at the time of an exception.

Thanks.

JonnyBee replied on Wednesday, December 16, 2009

Hi,

There are 2 separate issues that you may run into on Exception handling in serverside code.

1. Exceptions that are not Serializable (ex. MQException)
2. Exceptions from an assembly that is not available on the client.

Csla could handle #1 in a more graceful way - and extract info from a non-serializable exception into DataPortalException.

For #2 - the developer should make sure that only "standard .Net framework" or "known" exceptions are thrown back to the client.

RockfordLhotka replied on Wednesday, December 16, 2009

Look at the ErrorInfo property of the DataPortalException in Silveright. This contains the entire server-side exception hierarchy, though obviously not the server-side types (because as you note they don't exist on the client).

The CSLA .NET for Silverlight data portal, on the server side, rips the exception hierarchy apart and uses it to create the ErrorInfo hierarchy. That is then returned to the client, so the client has access to most of the exception data.

Copyright (c) Marimer LLC