5 ms·

> Optional catch binding Eh... that's great and all, but why not go the whole way and allow me to just use `try { }` without a catch-block? I'm sure that was

> Optional catch binding Eh... that's great and all, but why not go the whole way and allow me to just use `try { }` without a catch-block? I'm sure that was part of a conversation somewhere, and I wonder why they chose not to go that far.

goto11 7y ago
If it doesn't make any difference if the code inside the try block is executed or not, why even have the code in the first place? What is the use case for a try without a catch?
- recursive 7y ago
  Opportunistically loading from a cache
  - goto11 7y ago
    But if loading data from the cache fails, wouldn't you have to do something else to get the data? Or am I misunderstanding?
    - recursive 7y ago
      Only if you really need the data. Maybe it's nice-to-have.
thelazydogsback 7y ago
Or not require {} everywhere even for single statements, a la F#: try foo() with | ex1 -> failWith "doh!" and allowing these to be expressions rather than just statements. Exceptions become much easier to deal with this way: let result = try compute() with ex1 -> failwith "doh!" | ex2 -> -1
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.
  - 7y ago

goto11 7y ago

If it doesn't make any difference if the code inside the try block is executed or not, why even have the code in the first place? What is the use case for a try without a catch?

recursive 7y ago
Opportunistically loading from a cache
- goto11 7y ago
  But if loading data from the cache fails, wouldn't you have to do something else to get the data? Or am I misunderstanding?
  - recursive 7y ago
    Only if you really need the data. Maybe it's nice-to-have.

thelazydogsback 7y ago

Or not require {} everywhere even for single statements, a la F#: try foo() with | ex1 -> failWith "doh!" and allowing these to be expressions rather than just statements. Exceptions become much easier to deal with this way: let result = try compute() with ex1 -> failwith "doh!" | ex2 -> -1

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.
- 7y ago