Error handling in functions

[danyill]

scl-lib has a beautiful API in terms of returning edits and I've been enjoying it 👏

When creating the Stencil plugin recently I wanted to be very confident that all subscription and supervision changes had been successful.

I think some of our existing code has checks and nullish coalescing and other features which could result in a silent failure.

Should we return an "error code" or exit status perhaps a la Linux/Unix where we can positively affirm that everything functioned correctly. Or should our functions be written such that we can add these checks (e.g. for subscriptions that each ExtRef results in an appropriate item in an Edit array? This sounds a bit dubious).

Perhaps we need to return an edit array with an optional error result or throw an error from within scl-lib.
I think this needs some architecture and likely assistance from @ca-d.

[ca-d]

I have suggested to Jakob that we might throw an Error object in the places where something goes wrong. Later, at the call site, I can wrap the call in a try/catch statement and deal with the error as I like.

This allows return value types to remain unmodified and is the idiomatic way of dealing with errors in JavaScript and TypeScript alike.

[JakobVogelsang]

@danyill what do you think would this work for you?

[danyill]

Yes I think this is a good suggestion and it saves us from having to change the call signature which is a compatibility advantage and having support async/sync through the native Error all seems like an advantage.

I wonder if we need some standardised Error objects, e.g.

• SubscriptionError - Unable to complete a subscription due to e.g. an invalid control block or dataset reference
• SupervisionError - attempt to modify or add a supervision either not allowed or unable to create/add/delete a supervision

WDYT?

[ca-d]

This might be a great organizational tool given the size of this code base, I'd just want to make sure we extend one of the built in Error types and set a custom name property for each of our subclasses in the constructor, like so:

// example class for the kinds of subscription errors that are due to invalid references
class SubscriptionReferenceError extends ReferenceError {
  constructor(message) {
    super(message);
    this.name = this.constructor.name; // equals 'SubscriptionReferenceError' here
  }
}

That way, we make sure that call sites that check for Error types do catch us, and call sites that check for a particular error.name don't, just like they would expect.