You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we do a variety of different things to create an error with additional information out of an Error.t. Most of these involve converting the Error.t to a string with Error.to_string_hum and then creating a new exception with failwithf, Error.createf, Error.of_string, etc. This way, we end up with errors which are s-expressions encoded as strings in s-expressions encoded as strings etc.
Core has functions Error.tag : Error.t -> tag:string -> Error.t and Error.tag_arg : Error.t -> string -> 'a -> ('a -> Sexp.t) -> Error.t designed for adding this information without disrupting or string-encoding the underlying data. These are designed for this purpose, and we should use them!
Currently, we do a variety of different things to create an error with additional information out of an
Error.t
. Most of these involve converting theError.t
to a string withError.to_string_hum
and then creating a new exception withfailwithf
,Error.createf
,Error.of_string
, etc. This way, we end up with errors which are s-expressions encoded as strings in s-expressions encoded as strings etc.For example, in
coda_net2
we haveCore has functions
Error.tag : Error.t -> tag:string -> Error.t
andError.tag_arg : Error.t -> string -> 'a -> ('a -> Sexp.t) -> Error.t
designed for adding this information without disrupting or string-encoding the underlying data. These are designed for this purpose, and we should use them!The above example could easily be changed to
This has the added advantage of working nicely with #6698, which will accumulate these tags and print them as part of the JSON metadata that we log.
The text was updated successfully, but these errors were encountered: