0

As you all know exceptions is not serializable in general and after catching some very strange bugs in various serializers upon serialization/deserialization of different .NET Exceptions, I came up with simple DTO for trasport level:

[DataContract]
public class Error
{
    [DataMember]
    public string Message {get;set;}
    [DataMember]
    public string StackTrace {get;set;}
    //all Exception fields here
}

I can successfuly transform Exception to Error class, but how to do the opposite? I mean, I want to throw it after actual transportation, with valid remote stack trace and everything as it was before transportation... One way is to use Reflection, but, duh, it is awful and looks unhealthy.

eocron
  • 6,885
  • 1
  • 21
  • 50
  • 1
    Why? Exceptions already contain the call stack *and* can be serialized. A simple call to `ToString()` will return the message *and* stack trace. What you propose is what an Exception looks like in the first place. – Panagiotis Kanavos Apr 24 '17 at 09:39
  • Well, it is simple. It is NOT structured. So it will be hard to separate it in user interface or, for example, pipeline it into graylog or some log aggregator, where you can structurize your log for better understanding of errors. – eocron Apr 24 '17 at 09:41
  • No, it's not that simple. You are confusing exceptions with *logging* them. A *log* isn't a dump for exceptions and traces. An exception dump isn't a substitute for meaningful log messages. Besides, your snippet is just what an `Exception` object looks like in the first place. And Exceptions *are* serializable. – Panagiotis Kanavos Apr 24 '17 at 09:43
  • Instead of dumping exceptions and showing them to people that can't possibly understand them, ie users or client administrators, handle them properly and display meaningful messages. Log the exception string *only* in verbose developer logs. – Panagiotis Kanavos Apr 24 '17 at 09:45
  • You can try to put Exception field in WCF contract and see the opposite. You will not see actual exception until you enable special WCF trace variable. Just some abstract shit will come up. So, exceptions are not serialasable. – eocron Apr 24 '17 at 09:45
  • 1
    That would be a serious bug because SOAP already has its own Fault protocol. Violate it and your *clients* won't be able to communicate. Besides, you *don't* want to expose internals to untrusted clients. That's why it's standard practice to map exceptions to *different* Fault messages – Panagiotis Kanavos Apr 24 '17 at 09:46
  • 1
    What you are trying to do is already unhealthy so using reflection won't hurt, like in this question: http://stackoverflow.com/q/37093261/5311735 – Evk Apr 24 '17 at 09:46
  • @Evk an exception already contains the call stack. There is no need for reflection. In fact, the question itself hints at a bit of confusion around SOAP and WCF. This could become a scary security issue if the exception ends up in a SOAP message – Panagiotis Kanavos Apr 24 '17 at 09:47
  • @PanagiotisKanavos question is quite specific. You have a string with stack trace and want to attach that to an exception you are going to throw. No WCF, SOAP or anything like that is mentioned in question itself. – Evk Apr 24 '17 at 09:51
  • Well, you seem to not understand question: 1) Exceptions not serializable (try to figure out why some exceptions will not serialize/deserialize, for example in .NET Json), 2) It is for me to decide what to show to client, and what is not, so it's your opinion only. If I want to show message only - I DON'T NEED ToString() everything. 3) WCF is just one of many transport layers in system. So, yeah different serializers, different layers and so on. In between them I want to use Exception class istead of DTO. – eocron Apr 24 '17 at 09:51
  • 1
    If you don't want reflection - you can serialize exception into byte array with default .Net serializer (binary formatter), and pass it like that (as byte[] property). Then you should be able to deserialize it fine on client. Yes, that is also ugly, but again what you are trying to do is already arguable. – Evk Apr 24 '17 at 10:01

1 Answers1

2

Well I don't fully understood the requirement for doing this but in transport level communication there are always provision for error message/code passing for example WCF has fault-contract you can check. I have found an answer at Serializable Exception which might be suitable for your need. It has three ways of implementation and good code as well.

Community
  • 1
  • 1
Chaturvedi Dewashish
  • 1,469
  • 2
  • 15
  • 39