Hi,
Nice one!
Regarding backwards compatibility, existing modules that implement a
'format_error/4' function for their own purposes might be affected, no? Perhaps
the arguments won't match, the call will result in a badarg exception, which is
caught and ignored. But unintended consequences from a call by the exception
formatter can't be ruled out.
But the main point I want to raise is the following, and I do apologise if this
exceeds the original scope of the proposal: The 'format_error/4' callback
introduces an opportunity to suppress the value of sensitive parameters from a
stack trace.
For instance, suppose I call `crypto:mac(hmac, sha256, Message, Key)` and in
some code path Message ends up being `undefined`. The stack trace would
currently leak the key:
** exception error: {badarg,{"mac.c",216},"Bad key"}
in function crypto:mac_nif/4
called as crypto:mac_nif(hmac,sha256,undefined,<<"Supersecret">>)
The proposed format_error/4 callback allows the module, crypto in this case, to
customise the exception message below the 'called as' line. Perhaps the
callback could be extended to also allow the module to request
suppression/masking of (some of) the arguments on that line as well. In its
simplest form it might just return a flag requesting suppression of the actual
arguments, showing only the arity.
Again, I realise this is perhaps out of scope for the EEP's intended scope, but
it seems to me there is a window of opportunity to define the contract for the
format_error/4 callback, and once this EEP is implemented it is may become
harder to extend it to cover this additional use-case.
Regards,
Bram
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, November 4, 2020 7:18 AM, Björn Gustavsson <[email protected]>
wrote:
> There is a new EEP that suggests a way to show
> additional information about why a call to a BIF
> failed.
>
> Here is the EEP:
>
> https://github.com/erlang/eep/blob/master/eeps/eep-0054.md
>
> And here is the pull request for the implementation:
>
> https://github.com/erlang/otp/pull/2849
>
> /Björn
>
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Björn Gustavsson, Erlang/OTP, Ericsson AB
_______________________________________________
eeps mailing list
[email protected]
http://erlang.org/mailman/listinfo/eeps
