Request/Response - Throwing Exceptions in the Server

[arrkaye]

Hi,

This is more of a question than an issue for now.

We receive a MessageHandlerException on the client when thrown by the server with the below string fields set, but the InnerException is not set so we can't check the type using 'is' or obtain additional fields for exceptions that we've created.

public string InnerExceptionType { get; set; }
public string InnerStackTrace { get; set; }
public string InnerMessage { get; set; }

My question is, how do we properly propagate exceptions such that we can check them on the client?

Thanks,

Ark

[pardahlman]

Hi @arrkaye - binary serialization is not supported in earlier version of .NET Core (according to this article some exceptions can be serialized as of 2.0.4, more reading in this Github issue). In order to be compatible with these versions of .NET Core, the inner exception can not be transferred from the server to the client.

You should see the MessageHandlerException as an indication that the request has failed, and it gives you some information about the exception in order to be able to log and correlate the exception. The full exception will be captured in logs on the server side, if the server side uses a logging framework.

[arrkaye]

@pardahlman Thanks.

Does this also apply if we're using JSON.Net to serialize with Rabbit? AFAIK, this doesn't rely on the Exception implementing ISerializable..?

Reason I ask is that we were trying out EasyNetQ with .NET Core and that framework did propagate exceptions wrapped in a generic EasyNetQResponderException - which was nice from a client perspective.

[pardahlman]

Hmm, perhaps not. In earlier version of RawRabbit, the full exception was propagated but this stopped working after upgrading .NET Core version, which was when I switched over to a more lightweight representation of the error happening on the server side.

It would be interesting to see if exceptions could be serialized/deserialized with Newtonsoft.Json. But then again, RawRabbit has support for multiple serialization formats (protobuf, zero formatter and msg pack) so the functionality needs to be verified for these scenarios as well.

If it is important that the full exception is propagated, then perhaps EasyNetQ is a better fit for you. I'm a bit curios as to what you would do with the inner exception if materialized in the client application. It would have stack trace and state from a different application running on a different machine and be logged in the context of target of exception.