Summary
When some Throwable-related assertion fails the actual Throwable that failed the check is not described beyond what actually caused assertion failure (e.g. message mismatch). In non-trivial code when unexpected Exceptions are thrown this makes debugging inconvenient.
Dumping more comprehensive (class, message, stack, perhaps even recursive info about causes) info about the actual Throwable could ease assertion failure investigation.
Relevant message factories (e.g. ShouldHaveMessage) already have access to actual Throwable.
It may be tempting to use util.Throwables.ERROR_DESCRIPTION_EXTRACTOR to describe throwables, but a more powerful mechanism would be appreciated.
Providing precise information in case of assertion failure doesn't seem to be overkill (unlike as in #864)
Error message to improve
If you are interested in contributing to this issue, select one error message, it will be assigned to you.
Summary
When some
Throwable-related assertion fails the actualThrowablethat failed the check is not described beyond what actually caused assertion failure (e.g. message mismatch). In non-trivial code when unexpectedExceptions are thrown this makes debugging inconvenient.Dumping more comprehensive (class, message, stack, perhaps even recursive info about causes) info about the actual
Throwablecould ease assertion failure investigation.Relevant message factories (e.g.
ShouldHaveMessage) already have access to actualThrowable.It may be tempting to use
util.Throwables.ERROR_DESCRIPTION_EXTRACTORto describe throwables, but a more powerful mechanism would be appreciated.Providing precise information in case of assertion failure doesn't seem to be overkill (unlike as in #864)
Error message to improve
If you are interested in contributing to this issue, select one error message, it will be assigned to you.