- Home /
Rethrow an exception and display new exception's message in console? (C#)
I want to catch an exception, and rethrow with a more specific error message:
Dictionary<string, string> m_dictionary;
try
{
var value = m_dictionary["key"];
...
}
catch ( KeyNotFoundException e )
{
throw new KeyNotFoundException( "Error message.", e );
}
But Unity will display the original exception's error message in the console. It gives this:
KeyNotFoundException: The given key was not present in the dictionary.
Instead of this:
KeyNotFoundException: Error message.
Is there any way to get this behavior without throwing away the call stack information of the original exception?
It should be displaying the new message too, but further down where it says "rethrow as", right?
So the information you have added is there. Also, a client that catches your new exception will see your new message as the exception.message.
So I'm curious, what's your use case that makes it important that the new message appears at the top of the console entry when the exception isn't caught?
Yeah, it does provide the "rethrow as" message, but I feel the outer exception's information should be more readily available than that. When I see an error, I want to be able to look at the first message as it is displayed in the console and have that information be immediately useful.
If the dictionary in the example was a dictionary of states for a state machine, seeing "StateNotFoundException: state 'coolState' was not present in the State$$anonymous$$achine." is so much clearer than a $$anonymous$$eyNotFoundException.
So really I just don't want to have to do any thinking :P
That's fair enough. I think you're right that it would be more helpful shown the other way round, outer exception first,
Better to just use : if (!dictionary.TryGetValue(key, out value))
And do what exactly if key is in fact not found?
Answer by Bunny83 · Feb 17, 2016 at 08:03 PM
As Bonfire said the innermost exception is the most important and usually the most detailed exception. If an exception is catched by a more general system somewhere up the callstack, it usually don't know what exactly happend. They usually just add a more general exception as outer exception and keep the inner exception.
If you actually handle the exception properly and you want to provide a more detailed exception, you might want to remove the inner exception and just throw your customized exception.
However This approach is actually bad design, especially for realtime applications. A try-catch block adds quite a bit of overhead. Exceptions should never be used as a way of flowcontrol. If an exception can be avoided you should go that route.
In the case of a dictionary the method which does this is TryGetValue
string value;
if (m_dictionary.TryGetValue("key", out value))
{
// key was found, value has been filled.
}
else
{
// key wasn't found, take further actions.
// Either fill "value" manually if possible or throw an exception if there's no way around.
}
Finally some information on when to use exceptions and when not.