3 ms·

I expect it's because of `finally`. You can write a try without a catch today, provided there's a finally, however the error will continue to propagate in that

by rictic 7y ago

I expect it's because of `finally`. You can write a try without a catch today, provided there's a finally, however the error will continue to propagate in that case. try {throw new Error('')} // exception is caught try {throw new Error('')} // uncaught exception finally {console.log('finally')} That would be a bit of a footgun, as adding a finally clause that does something innocuous like logging would result in an uncaught exception!

ravenstine 7y ago
That makes sense. I guess `try` means something a bit different in JavaScript than `rescue` does in Ruby. It seems like this code in Ruby: ``` begin do_something rescue => e handle_error e ensure log_something end ``` is equivalent to this in JavaScript: ``` try { doSomething(); } catch(e) { handleError(e); } finally { logSomething(); } ``` I'm not saying that they're 100% equivalent, but I was thinking of the `try` block as if it's `rescue` when really it has more in common with `begin` in Ruby in that it's defining a block of code that can be rescued/caught if an error occurs. So I guess my confusion comes from this type of block being named `try` rather than something like `do` or `begin`. TL;DR I was just thinking about this in the wrong way from what I can tell. EDIT: Yet I think that my point might still stand in that, if `try` is just a block that has its own scope, like an if-block or `begin` in Ruby, then it should be possible to not require either `catch` or `finally` since its own behavior has little to do with error handling. For instance, this is possible: ``` let x = 'foo'; try { let x = 'bar'; } catch(err) { // noop } console.log(x); // foo ``` The try-block would be way more useful if it could just define scope without being tied specifically to error handling. There are lots of circumstances where defining scope would be handy outside of conditionals and creating functions for a similar purpose. I guess what might have made the most sense, if JS could have started over, is that there'd be no `try` statement and that `do` could be used in its place. ``` const words = ['foo', 'bar', 'baz']; let i = 0; do { console.log(words[i]); i++; } catch(err) { console.error('whoops!'); } while (i < words.length); ``` We can't go back now since JS, for good reasons, is remaining mostly backwards-compatible. But the ability to do the above without extra gymnastics would be pretty cool.
- rictic 7y ago
  > The try-block would be way more useful if it could just define scope without being tied specifically to error handling. There are lots of circumstances where defining scope would be handy outside of conditionals and creating functions for a similar purpose. This is the case today! With `let` and `const`, any {} block creates a scope. So: let foo = 'outside'; { let foo = 'inside'; console.log(foo); // logs 'inside' } console.log(foo); // logs 'outside'

by rictic 7y ago

ravenstine 7y ago

That makes sense. I guess `try` means something a bit different in JavaScript than `rescue` does in Ruby. It seems like this code in Ruby: ``` begin do_something rescue => e handle_error e ensure log_something end ``` is equivalent to this in JavaScript: ``` try { doSomething(); } catch(e) { handleError(e); } finally { logSomething(); } ``` I'm not saying that they're 100% equivalent, but I was thinking of the `try` block as if it's `rescue` when really it has more in common with `begin` in Ruby in that it's defining a block of code that can be rescued/caught if an error occurs. So I guess my confusion comes from this type of block being named `try` rather than something like `do` or `begin`. TL;DR I was just thinking about this in the wrong way from what I can tell. EDIT: Yet I think that my point might still stand in that, if `try` is just a block that has its own scope, like an if-block or `begin` in Ruby, then it should be possible to not require either `catch` or `finally` since its own behavior has little to do with error handling. For instance, this is possible: ``` let x = 'foo'; try { let x = 'bar'; } catch(err) { // noop } console.log(x); // foo ``` The try-block would be way more useful if it could just define scope without being tied specifically to error handling. There are lots of circumstances where defining scope would be handy outside of conditionals and creating functions for a similar purpose. I guess what might have made the most sense, if JS could have started over, is that there'd be no `try` statement and that `do` could be used in its place. ``` const words = ['foo', 'bar', 'baz']; let i = 0; do { console.log(words[i]); i++; } catch(err) { console.error('whoops!'); } while (i < words.length); ``` We can't go back now since JS, for good reasons, is remaining mostly backwards-compatible. But the ability to do the above without extra gymnastics would be pretty cool.

rictic 7y ago
> The try-block would be way more useful if it could just define scope without being tied specifically to error handling. There are lots of circumstances where defining scope would be handy outside of conditionals and creating functions for a similar purpose. This is the case today! With `let` and `const`, any {} block creates a scope. So: let foo = 'outside'; { let foo = 'inside'; console.log(foo); // logs 'inside' } console.log(foo); // logs 'outside'