Exploring Hatchet API design options for passing errors through

hatchet_errors.rb

# Exploring API design options as it's hard to think of something that's
# aesthetically pleasing that also avoids needless string interpolation.

# Multiple return arguments.
#
# Syntax looks a little weird with the multiple brace types.
log.error { ["Some message", e] }
log.error {[ "Some message", e ]}

# Passing the exception as an optional parameter.
#
# Breaking change and order feels a little backwards.
log.error(e) { "Some message" }

# Params hash.
#
# Double braces is odd and there's a higher chance of typos.
log.error {{ message: "Some message", error: e }}

# Suggestion by @stephenbinns
#
# Non-block method.
log.error "Some message", e

# And if your message is expensive to create and not always logged:
log.error("Some message #{expensive}", e) if log.error?

# Other?

I think so, users can always make use of the log enabled methods if they have expensive string interpolation in these cases

Given that an exception will/should be a subclass of StandardError. Could you allow an error to be passed instead of a message?

log.error e
log.error { "Some message #{some_state}" }

Not sure how you'd best do this idiomatically but from an API point of view it would read well.

A log and a message would be more useful imo so you can add some extra context to it e.g. what method threw the exception, is this an exception which requires further action etc.

Side note: Adding the exception does raise a question in my head as to how these exceptions should be formatted?

I think you have to provide a message to give context to the exception and so they should be passed together. Or did you mean pre-loading the exception to be picked up with the next message?

The formatting of the exception into/alongside the message would be the responsiblity of the formatter(s).