Error Handling

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

Errors BotAction

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:

Copy
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

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.