New EEP for extended error information

[Björn Gustavsson]

On Wed, Nov 4, 2020 at 8:12 AM Bram Verburg <bram.verburg@REDACTED> wrote:
> Nice one!

Thanks!

> 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.

There must be an {error_info,ErrorInfoMap} in the stack trace for
format_error/4 to be called, so there should not be any immediate
backward compatibility issue for existing code.

There is a suggestion in the EEP that ErrorInfoMap could be extended
in the future with module and function keys to point out an alternate
format_error/4 function with an arbitrary name.

> 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.

I will discuss it with the team, but it does seem to be outside the
scope of this EEP.

> 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.

Yes, it is good to ensure that any essential features are there from
day one, but we do have flexibility in the future for extensions
because of the maps (in the stacktrace and as return value from
format/4).

/Björn

-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB