I was lloking at the implementation of DtoUtils.CreateErrorResponse(request, exception);
and then the implementation DtoUtils.ToResponseStatus(ex) (that CreateErrorResponse uses).
public static ResponseStatus ToResponseStatus(this Exception exception)
{
IResponseStatusConvertible statusConvertible = exception as IResponseStatusConvertible;
if (statusConvertible == null)
return DtoUtils.CreateResponseStatus(exception.GetType().Name, exception.Message);
return statusConvertible.ToResponseStatus();
}
I think it’s not correct to just drop ex.Message … the concatenation of all messages of the innerexception chain should be provided (if any)
something like
return DtoUtils.CreateResponseStatus(exception.GetType().Name, exception.AllMessage());
where AlMesasges is the extension method below
public static string AllMessages(this Exception ex)
{
var sb = new StringBuilder();
while (ex != null)
{
sb.Append(ex.Message);
if(ex.InnerException!=null)
sb.Append(" --> ");
ex = ex.InnerException;
}
return sb.ToString();
}
personally in my custom implementation I’d just drop an ex.ToString() which returns a nice string with the messagge exception chain and the stack trace
It uses the first Exception message as it needs to be a human friendly enough error message that can be displayed inside an error placeholder, not a dump of all error messages. We have the server StackTrace for that, but it needs DebugMode to be enabled for the StackTrace to be populated.
Hi, thank you for the reply
The stacktrace is just the stacktrace … it DOES NOT contain any error message information.
The message of the first exception in the chain is just the first one, it’s not necessarly human friendly (almost never unless you setup up your code in order to do so), AND often is not the usefull one to troubleshoot a problem (the usefull one is sometime one of the inner exception).
For logging stuff, using ex.ToString() is the best option it dumps err1.msg -> err2.innermsg – > etc … then the stack trace.
My point is that unless one code in order to make sure the external excpetion is always targeted to the end user, the added value of the outer ex.message is quite random.
I would suggest to stuff ex.tostring() as erromesage in debugmode and outerexception.Message (as you do now ) when not in debug mode.
By default it returns the InnerException which can be disabled with Config.ReturnsInnerException = false.
You can customize the Error ResponseStatus DTO by overriding OnExceptionTypeFilter() in your AppHost, at which point you can choose to use ex.ToString() in the StackTrace instead.
that’s ok. I noticed I can control everything regarding this flow.
I was just pointing to a sub-optimal (in my opinion) implementation of the default behaviour