orleans: [question] Exception deserialization

Lately I got a strange exception in my logs that read TypeLoadException: Could not find EntityFramework.dll.

After some investigation it turned out that my data access layer (which is referenced by my Orleans server-side code) issued an EntityException which bubbled up to Orleans, travelled over the wire, but on the client it could not be deserialized since the client does not (and should not) reference EntityFramework.

I’m not interested in the concrete exception type – simply want to log the unknown exception with ex.ToString() on my client.

What is the best way to accomplish this? I don’t want to repackage each possible exception into a “client-side readable” well-known exception in (server-side) grain code like this:

try
{
  // ...
} catch (Exception e)
{
  // send a client-side known exception over the wire
  throw new ClientSideKnownException(e.ToString());
}

Any suggestion how to handle this?

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 27 (27 by maintainers)

Commits related to this issue

Most upvoted comments

Sorry, I found the MD files under ...\src\Documentation\.... I’ll try to get along…

Today I revisited the docs and read the “interceptor” chapter. My question is: What about putting a try-catch-block into a silo-level interception method and rethrowing those exceptions which are unknown from the client’s perspective (e.g. EntityException)? If you don’t veto, I would give it a try.

Seems like another use case for interceptors. Great that it already worked for you. If you could add a paragraph to the interceptors docs, that would make it a potentially reusable pattern for others.

Alternatively, you should be able to write your own serializer (we now support “External serializers”), where you simply delegate the serialization for all types to Orleans except for this one type from EntityFramework.dll which you serialize yourself into a simple Exception.