Today, I worked with services logic that sends me light objects mapped from NHibernate entities with AutoMapper, and I got an exception stating that something is wrong with mappings. I wrote UT that reproduces my issue and surrounded code with try{}catch(){} to see exception closer, and it said me the same I saw. I took a look on Inner exception message and at first glance it was absolutely identical to parent message.
Then I spent about 10-20 minutes verifying all my entities, trying to find some stupid mistake and I would spend more if I would not take a look on Inner exception of the Inner exception and it was a bit different, saying that another entity mapping is wrong, so I took a look into Inner exception of it and so on…
So do you have an idea where did I stop? See:
So I went through 11 Inner Exceptions to get to the null Inner Exception :) Highlighted message provided me information I needed to resolve my issue.
Moral: Always take a look into Inner Exception!
3 comments
| Markdown | Result |
|---|---|
| *text* | text |
| **text** | text |
| ***text*** | text |
| `code` | code |
| ~~~ more code ~~~~ |
more code |
| [Link](https://www.example.com) | Link |
| * Listitem |
|
| > Quote | Quote |
"Moral: Always take a look into Inner Exception!" Or don't use AutoMapper ))
In the our project we use helper who can contact all error messages, maybe it will be helpful for someone:
public static string ExceptionPresentation(Exception ex)
{
StringBuilder sb = new StringBuilder();
do
{
sb.Append(ex.Message);
sb.Append(' ');
ex = ex.InnerException;
sb.AppendLine();
}
while (ex != null);
return sb.ToString();
}
1. Ihor, this method looks good, in my example it would be 2 A4 pages of text :)
2. Also, without AutoMapper code of our enterprise project could have 2-5 inner exceptions.
3. I believe that we are logging stack trace in debug mode.
4. The more sophisticated mappings I wrote the more I think about rationality of using AutoMapper…
AutoMapper is especially superior to hand-made converters, when you have a cyclic data structures.
In general, "never" is never good option :)