search

tc39 / proposal-pipeline-operator

A proposal for adding a useful pipe operator to JavaScript.
http://tc39.github.io/proposal-pipeline-operator/
BSD 3-Clause "New" or "Revised" License
7.55k stars 108 forks source link

Error Handling #299

Closed lauhon closed 3 months ago

lauhon commented 1 year ago

In F# you can use Railway Oriented Programming to deal with errors in a Functional way.

Railway Oriented Programming is a really neat concept that enables super readable and explicit code. Libraries like neverthrow "artificially" add those concepts by providing some utility classes, maybe this can be further integrated into JavaScript.

In this Proposal, there is not much explicit information about how errors could be handled with the new pipe operator. When reading through it there are some questions popping up in my head. I am not sure if this is needed for the proposal, but I thought I would share it in this Issue in the hope that it adds to the discussion :)

Will downstream function calls be omitted if an early function throws an error? Will JS Programmers need to create a Result Type/Object themselves to deal with this, or should there be something out of the box in JavaScript? Is "Error Mapping" going to be a thing that's integrated into the new pipe syntax?

nicolo-ribaudo commented 1 year ago

Will downstream function calls be omitted if an early function throws an error?

Yes, similarly to how in foo(bar()) foo is never called if bar throws an error.

bogdanbiv commented 3 months ago

In this Proposal, there is not much explicit information about how errors could be handled with the new pipe operator.

If any of the earlier functions throw, it interrupts the flow and further calls are not done. If an error is returned, then yes receiving functions need to check if they received an error or a Result. This proposal does not add any Result / Error types in returns. Handling these needs to be done in all receiving functions.

Error mapping? I guess there's no specific handling for Errors. IMO you should use Promises to pass from one level to the next. We cannot make JS into Rust or Haskell, unfortunately we are limited in scope and this seems out of scope

tabatkins commented 3 months ago

Yup, there's nothing special about this syntax wrt errors; an error thrown by one expression in a pipeline will interrupt execution and pass up the calling context, exactly like just executing those expressions without the pipe. And the same "exactly like ... without the pipe" applies generally to error-handling; we don't intend to reinvent JS's error handling in this proposal. (Even if monadic errors are cool.)