ca-d
commented
2 months ago 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.
scl-lib has a beautiful API in terms of returning edits and I've been enjoying it :clap:
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.