-
-
Save marianoguerra/dc2e0aa73964f0e501f4b4433368ee00 to your computer and use it in GitHub Desktop.
Standard Error Format for Erlang
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
-record(error, {type, ctx}). | |
% TODO: macros to create error adding module, line and function to context | |
% TODO: line(#error{}), module(#error{}), function(#error{}) to return those fields if defined or undefined if not | |
% TODO: pretty printer | |
new(Type) -> new(Type, #{}). | |
new(Type, Ctx) -> #error{type=Type, ctx=Ctx}. | |
wrap(Type, Cause=#error{}) -> wrap(Type, Cause, Ctx). | |
wrap(Type, Cause=#error{}, Ctx) -> | |
#error{type=Type, ctx=maps:merge(Ctx, #{cause => Cause})}. | |
cause(#error{ctx=#{cause := Cause}}) -> {ok, Cause}; | |
cause(#error{}) -> notfound. | |
get(Error=#error{}, Key) -> get(Error, Key, undefined). | |
get(Error=#error{ctx=Ctx}, Key, Default) -> maps:get(Key, Ctx, Default). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
for people joining the conversation my latest code is here: https://github.com/marianoguerra/einfo
@andytill I made it a record because you mentioned R16 compat and because of @mrallen1's comment, I can change it to generate a map in a couple of minutes.
Regarding the fields, the ones in the record are quite standard and not supposed to change much, any other field could go in extra, we can brainstorm for some extra fields to add on #einfo{} and then seal it forever if we don't move to a map.
I would prefer it to be a map with standardized fields and use the parse transform for convenience, if people don't like the parse transform they can still use the macros and get the same result, or use functions and loose the location info.
Regarding the location fields, it's runtime free (except space), it's nice extra context to go look at and can be useful in the case where the error comes from a case/function clause not matching this error somewhere upstream but not your code and you get just "exception error: no case clause matching {error,badarg}", this would tell you where the error actually was generated and gives you an idea of what may have caused it.
just some ideas, I'm open to any kind of change as long as we get something usable that helps troubleshoot weird errors :)