Allow returning stacktrace on errors in transaction type spec #20
Conversation
maximvl
force-pushed
the
add_transaction_stacktrace
branch
from
717b603 to
d3d75b5
Compare
| language: erlang | ||
| otp_release: | ||
| - 20.2 | ||
| - 20.3 |
There was a problem hiding this comment.
Actually, let's add -21.3 too, or just replace it.
|
@maximvl I think I disagree with this, what API function returns the stack trace? That is something it should be handled by the caller. |
|
@cabol it's up to an adapter to implement this feature, but if there is an error inside transaction we only return the message which is most of the time something like |
| Fun :: fun(() -> any()), | ||
| Opts :: xdb_lib:keyword(), | ||
| Res :: {ok, any()} | {error, any()}. | ||
| Res :: {ok, any()} | {error, any()} | {error, any(), [tuple()]}. |
There was a problem hiding this comment.
@maximvl according to your thought it's up to an adapter to implement this feature, I think we shouldn't modify this spec, {error, any()} should be enough, you can pass the ST like {error, {Reason, ST}}, again, it is up to the adapter right?
There was a problem hiding this comment.
@cabol in a way yes, but the problem is the original error might look like {Reason, Data} and then it becomes hard to know for sure.
2 participants
Hi, the idea here is to allow adapters to return stacktrace on transaction errors as this simplifies debugging a lot. The caller can control it via transaction
Optssecond parameter, something like[{return_stacktrace, true}]