Error handling are omitted from the main Assembly Lines. They don't catch errors, and this was done in favor of creating a composable solution for helping devs find errors in deeply nested assembly lines.
Debugging async code can be hard & time consuming. The solution here catches errors in a nestable way to isolate where errors are being thrown in complex BotAction lines. The solution is a BotAction called
errors()() wraps assembled BotAction's in a try/catch, to log errors caught in the NodeJS console with an "Errors Block Name" provided in the first
errors() call. Let's see an example:
await chain(errors('News Scraper')(// actions here are ran in a wrapped try/catch:goTo('site to scrape'),),log('this runs, even if errors()() catches an error'))(page)
So if a BotAction, in the assembled
errors()() second call, throws an error, the error is caught and logged by the higher
errors()() BotAction. After an error is thrown, the remaining assembled actions are ignored, and the higher line of BotAction's continues. So if an error is caught in the "News Scraper" block, the sibling
log() BotAction will still run, but any remaining BotAction's assembled in
errors()() is skipped.
Nesting to isolate errors
errors()() is nestable as deeply as necessary. This is to isolate the origins of tough to find async errors. The closest parent
errors()() block will swallow the thrown error. Any higher
errors()() blocks will not see it. Therefore,
errors()() can "block" your code, in various scopes, into separate identifiable parts, for isolating async errors.
Works in Pipe or Chain
Edit this page on GitHub
errors()() checks the higher order context
injects for a Pipe object, to determine how it runs the assembled actions. If a Pipe object is detected, it runs the assembled BotAction's in a Pipe otherwise, it defaults to a Chain. This keeps the assembly style consistent with the parent scope.