The process of retrieving the string representation of an Exception - engine.Exception.Error() - is found to be inconsistent across multiple calls. The first call returns the accurate error message, but the second and subsequent calls return the string ....
The following minimal code demonstrates the issue:
In the first call, the table of visited compounds is populated, leading to the accurate error message. However, in subsequent calls, as the compound has already been visited, the writer generates the string ... instead. π
Impact
This side effect is particularly unexpected as it's common to get consistent string returns from exceptions.
Additionally, the effect is quite subtle in the context of our unit tests using smartystreets/goconvey, where assertions are structured as follows:
In this scenario, the first call (which is introspective) generates an accurate error string. However, on the second call, the output becomes ..., which is unfortunately incorrect. π₯
Issue
The process of retrieving the string representation of an Exception -
engine.Exception.Error()
- is found to be inconsistent across multiple calls. The first call returns the accurate error message, but the second and subsequent calls return the string...
.The following minimal code demonstrates the issue:
Analysis
The issue appears to originate from the global variable engine.defaultWriteOptions used for managing the compounds already visited in the string conversion process of the
engine.Exception
.In the first call, the table of visited compounds is populated, leading to the accurate error message. However, in subsequent calls, as the compound has already been visited, the writer generates the string
...
instead. πImpact
This side effect is particularly unexpected as it's common to get consistent string returns from exceptions.
Additionally, the effect is quite subtle in the context of our unit tests using smartystreets/goconvey, where assertions are structured as follows:
In this scenario, the first call (which is introspective) generates an accurate error
string
. However, on the second call, the output becomes...
, which is unfortunately incorrect. π₯