0

I was trying to map 2 kinds of exceptions (one from an external lib to a type that belongs to my application):

CreateMap<PermissionException, MyException>()
                .ForMember(dest => dest.Error, opt => opt.MapFrom(src => src.Error))
                ;

This would create an exception with the following message : Instance property 'Current' is not defined for type 'System.Collections.IDictionaryEnumerator'

This exception happens whatever exception I'm trying to map. A bit of debugging got to the point where I found that the Data member was the one having issues. So I changed my mapping configuration to this:

CreateMap<PermissionException, MyException>()
                .ForMember(dest => dest.Error, opt => opt.MapFrom(src => src.Error))
                .ForMember(dest => dest.Data, opt => opt.Ignore())
                ;

Which seems to fix the issue.

I've looked around and there does not seems to be anything special that needs to be done for mapping exception. So I'm wondering if this is a bug or if there is something I'm doing wrong ?

Thanks for your insights.

MaxouMask
  • 985
  • 1
  • 12
  • 33
  • 1
    No, but the non generic `IDictionary` is not supported. So `Ignore` and carry on :) – Lucian Bargaoanu Jan 21 '21 at 15:01
  • 1
    Arguably mapping exceptions this way is the wrong way to go; you can construct a `MyException` that has the `PermissionException` as the `InnerException`. Simply adopting third-party exceptions as if they were your own without wrapping them leaves you open to potentially interesting conflicts between the scope and style of messages. – Jeroen Mostert Jan 21 '21 at 15:39
  • @JeroenMostert makes a very good point! – Lucian Bargaoanu Jan 21 '21 at 16:35
  • @JeroenMostert: I'm not sure to get what you mean. Would you be kind enough to explain a bit ? – MaxouMask Jan 21 '21 at 17:12
  • `try { ... } catch (PermissionException e) { throw new MyException("My exception!", e); }`. `Exception` has [a constructor for just this purpose](https://learn.microsoft.com/dotnet/api/system.exception.-ctor#System_Exception__ctor_System_String_System_Exception_), which your class can call. – Jeroen Mostert Jan 21 '21 at 17:21
  • I got the part about using as an inner exception. I was more referring to `Simply adopting third-party exceptions as if they were your own without wrapping them leaves you open to potentially interesting conflicts between the scope and style of messages.` This was the part of the comment that did not really understand the implications of. – MaxouMask Jan 22 '21 at 08:50
  • By that I mean: let's say the third-party exception throws a `WidgetException` deep in a call stack somewhere that says "Buffer too small" (or "code 434"), and you end up presenting this message as a `MyException` -- this is far less useful than a `MyException` that says "Storing user details failed" with an `InnerException` that contains the nasty details. It's a bit like letting a `NullReferenceException` escape. Having mapping for exceptions encourages poor error handling by treating everything as a top-level exception and mapping it, instead of wrapping them as higher-level errors. – Jeroen Mostert Jan 22 '21 at 13:49
  • Ok got it. Thanks for the explanation. – MaxouMask Jan 22 '21 at 14:43

0 Answers0