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?

@adambird wants to be able to pass errors into Hatchet for Airbrake integration. I haven't needed this, instead I've been formatting them into my messages. However, it is a common feature of logging frameworks so I makes sense to add it.

The problem is I can't think of a way of optionally passing an error that looks nice to me. The three main ways I've thought of are above, any input gratefully received.

of those options the first looks the cleanest to me.

If you were introducing a breaking change you might want to follow the Log4X.. format e.g

log.warn("Some message", e)

That then means any string interpolation will be performed, even if the message won't be written.

log.warn("Some message #{expensive.to_s}", e)

However, the case of having an exception and it not being logged at a level that would be written is probably an odd one so it might be worth the sacrifice for clarity.

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