(start) calls handler with error combiner instead
#197
Conversation
This file contains 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
i already shot my shot with the 'a nu start' joke, but it'd be better applied here. oh well. previously (start) would call the function with a bool indicating success. if the handler raised an error, it would actually be used to wrap the root error. this was always a little surprising. meanwhile the handler had no way to access the root cause of the error, e.g. to log it using cli.WriteError(ctx, err), which I need to do in Bass Loop. now the handler is called with a nullable combiner. if null, the thunk succeeded. if a combiner is present, it can be called to propagate the error to whoever waits on the thunk run. to accomplish this a special Error combiner value has been introduced. it displays like <error: inner error msg> and when called returns the inner error.
vito
added
enhancement
vito
changed the title
(start) calls handler with error combiner instead
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
previously
(start)would call the handler with a bool indicating success. if the handler raised an error, it would actually be used to wrap the root error. this was always a little surprising.meanwhile the handler had no way to access the root cause of the error, e.g. to log it using cli.WriteError(ctx, err), which I need to do in Bass Loop.
now the handler is called with a nullable combiner. if null, the thunk succeeded. if a combiner is present, it can be called to propagate the error to whoever waits on the thunk run.
to accomplish this a special Error combiner value has been introduced. it displays like <error: inner error msg> and when called returns the inner error.
the new implementation of
(succeeds?)and(run)feel a bit cleaner: https://github.com/vito/bass/compare/anustart?expand=1#diff-23e0b46edf759eda1782b1de1613ddb63c137769ab51736200319a85ccde9d6cside note: this is continuing along an "everything is a combiner" trend, which feels pretty intuitive for errors imo: errors are often wrapped, i.e. combined. so this combiner could be tweaked to take a wrapping message or something if we want. maybe a string and fields to avoid formatting and maintain symmetry with
(error)?