Error Handling

[lauhon]

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]

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]

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]

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