DEV Community

loading...

Discussion on: Best Practices for ES6 Promises

Collapse
somedood profile image
Basti Ortiz (Some Dood) Author

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.

Collapse
richytong profile image
Richard Tong

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!

Thread Thread
somedood profile image
Basti Ortiz (Some Dood) Author

Yup, I was coming from the mindset that try/catch blocks are kinda "clunky", which is why I stylistically preferred Rust's error handling.

I'm neck deep in functional JavaScript...

Wise decision. The functional style is indeed beautiful. I never liked try/catch blocks anyway. 😂