Show stack traces on assertion errors

[ethanfrey]

Summary

assert.NoError(t, err) typically dumps out a stack trace of the error, which is a wonderful help for debugging. This is based on pkg/errors work and is pretty much the standard in golang error handling since 2016 or 2017. cosmos-sdk shows no such stack traces

Problem Definition

This feature was present in older versions of the sdk. And all the groundwork is already done

Proposal

stretchr/testify the popular testing library used by cosmos-sdk, has nice support for showing stacktraces in NoError: return Fail(t, fmt.Sprintf("Received unexpected error:\n%+v", err), msgAndArgs...)

Note the use of %+v, which is a special rune used by pkg/errors

After digging into sdk code, I found that there is support for stacktraces in cmnError which seems to be the root of the inheritance jungle. It even has Format implemented. The only problem is that it chooses to display the stacktrace upon %#s, %#v, %#q, etc... https://github.com/tendermint/tendermint/blob/master/libs/common/errors.go#L127-L133

I don't know if changing tendermint implementation is an option (and out of scope here), but you could override the Format method in sdk.Error to give a behavior more in line with standard packages.

Or for a deeper changes, you could look at small, well-designed error handling package that captures sdk errors with codes and even handles joining multiple validation errors into one response.

I'm happy to discuss this more, but presence of stack traces in failing tests (without requiring a panic) is a huge productivity enhancement.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[jackzampolin]

I think @fedekunze might have the best context here.

[alexanderbez]

This essentially ties into removing cmn.Error correct? I think @marbar3778 is spearheading this.

[fedekunze]

Closed via #4821