mattn / anko

By using "%v" in here and few other places:

Line 316 in a13910f

runInfo.err = fmt.Errorf("%v", recoverResult)

Only short error string is propagated outside, the origin full stack trace is lost.

Can "%+v" be used here ?

The full stack trace is not wanted for the error message all times because sometimes the error needs to be matched/checked.

The full stack trace is not wanted for the error message all times because sometimes the error needs to be matched/checked.

But more times I wanted to track down where is the trigger point from application code, this is much desired for troubleshooting against a production system, and very hard to figure out without detailed stack trace.

Or can runInfo.err be storing the original error object for application to inspect, instead of converted string?

I sometimes want to see the full stack trace as well but I think the more common case is people want the simple error message. The debug option is there for the times when the full stack trace is wanted.

If you are looking for another way Anko to save the full stack trace a custom error message might be possible however I personally do not see high value in adding that to Anko.

I would suggest instead adding additional logging in the production code to help track down the issue.

In my case, - building a framework that depending on Anko to host execution of application code with a controlled environment, the error handling, including logging is better handled at the framework level.
There has been a custom errors module defined to create error objects carrying full stack trace info, expected to bubble up back to the framework, but those are stripped by Anko unless run in debug mode.
I think I need an option to communicate with Anko that I expect error passing through from scripting code.

Let me try to be more clear. I am generally fine with improved error handling. In my large list of things to do, improving the error handling is low on my list.

If someone wants to improve Anko error handling, a high quality PR would probably be accepted (Matt has final say). I am not exactly sure what that PR would look like but I am pretty sure that the default error would need to still be easy to check, similar to how it can be used currently.

Sure, I'm to draft one or another PR to investigate into possible options and discussions there. Thanks @MichaelS11

detailed error stack lost if not in debug mode