That is definitely a more practical approach. Personally, I've recently found Rust's error handling idioms more elegant than that of JavaScript promises. They have this notion of a Result type that I really like. I'll be writing about it in the near future, where I'll advocate for its usage with JavaScript promises.
Regarding the part you quoted, I would like to add that I was careful to say "may reject" since there are some promises that cannot possibly reject. For example, it is unreasonable to attach a catch handler for Promise.resolve. Something along those lines.
Found rust docs on error handling. The thing is, I like exceptions, and I like that all errors thrown in JavaScript behave pretty much like panic!. Rust provides language semantics to differentiate between recoverable errors (Result) and unrecoverable errors (panic!). However, I don't really see how this is better than throwing errors. Perhaps try/catch blocks are clunky? I should mention that I'm neck deep in functional JavaScript and I don't even use try catch blocks, just tryCatch. <- catches synchronous errors and rejected Promises, also disclaimer that I wrote that function
On "may reject", I think I was triggered by the "always", but touche!
That is definitely a more practical approach. Personally, I've recently found Rust's error handling idioms more elegant than that of JavaScript promises. They have this notion of a
Resulttype that I really like. I'll be writing about it in the near future, where I'll advocate for its usage with JavaScript promises.Regarding the part you quoted, I would like to add that I was careful to say "may reject" since there are some promises that cannot possibly reject. For example, it is unreasonable to attach a
catchhandler forPromise.resolve. Something along those lines.Found rust docs on error handling. The thing is, I like exceptions, and I like that all errors thrown in JavaScript behave pretty much like panic!. Rust provides language semantics to differentiate between recoverable errors (Result) and unrecoverable errors (panic!). However, I don't really see how this is better than throwing errors. Perhaps try/catch blocks are clunky? I should mention that I'm neck deep in functional JavaScript and I don't even use try catch blocks, just tryCatch. <- catches synchronous errors and rejected Promises, also disclaimer that I wrote that function
On "may reject", I think I was triggered by the "always", but touche!
Yup, I was coming from the mindset that
try/catchblocks are kinda "clunky", which is why I stylistically preferred Rust's error handling.Wise decision. The functional style is indeed beautiful. I never liked
try/catchblocks anyway. 😂