Improve handling of Exception<T> where T : struct

[niemyjski]

@corneliutusnea commented on Wed Aug 12 2015

We use an Exception which gets rendered a bit oddly in the UI.
public class CustomException : ApplicationException
where T : struct
We use this so we can use enums instead of strings for error messages that are then easy to group in "buckets" or localize.

The the EL UI they get rendered as:
My.Custom.Namespace..CustomException`1[[Some.Long.Name.Space.ErrorCategory_ErrorBucket, Long.AssemblyName., Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]]

EL should understand such exceptions and render them as:
CustomException<ErrorCategory_ErrorBucket>

---

@niemyjski commented on Thu Aug 13 2015

Yeah, I agree this should use the namespace+typename and not the assembly full name.

---

@niemyjski commented on Thu Aug 13 2015

It also looks like the grids are having issues with these type names too.

[niemyjski]

We need to add tests for this.

[Jaans]

Running into this one too :-(

We are having a similar problem with ServiceModel exceptions that have generic Fault<>types.

If it helps, here's an example of how it presents in the UI:

As you can see it's a bit hard to see what it is without hovering for a tooltip for each one.

[niemyjski]

That's not good at all, is there any chance you could add some tests for this or snippet. Looks like we'd just need to update the Error Plugin and how it shreds the error into our model.

[Jaans]

Thank you!

This should be enough to get you to repro the behaviour:

var exception = new DivideByZeroException("Oops!");
var exceptionDetail = new System.ServiceModel.ExceptionDetail( exception );
var faultException = new System.ServiceModel.FaultException<System.ServiceModel.ExceptionDetail>( exceptionDetail, "Service has failed" );

// Send it to exceptionless
throw faultException;

Let me know if you need more info.

[elachlan]

Relates to #177

This is still a problem after Demystifier was implemented.

The error plugin uses ToErrorModel

Exceptionless.Net/src/Exceptionless/Plugins/Default/020_ErrorPlugin.cs

Line 21 in 118b006

context.Event.Data[Event.KnownDataKeys.Error] = exception.ToErrorModel(context.Client);

Should it being using ToSimpleErrorModel, which makes use of Demystifier? Or should it use the SimpleErrorPlugin? They seem like they set different data though. So maybe add Demystifier to the Error Plugin?

[niemyjski]

Both implementations should use demystify which I don't think would have fixed this issue. We need to better handle this in ToError()

[elachlan]

@niemyjski see #272