Created
November 2, 2012 09:28
-
-
Save gshutler/3999740 to your computer and use it in GitHub Desktop.
Exploring Hatchet API design options for passing errors through
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
| # 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? |
Author
Author
The formatting of the exception into/alongside the message would be the responsiblity of the formatter(s).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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?