Discussion on: Nulling JavaScript

[Ryan Palo]

Is there a reason not to use a Try/Catch block? That seems a little more explicit, but I'm not sure, maybe that's not idiomatic for JavaScript. I haven't done enough big JavaScript to know. At least in Python, it seems like it would work well enough to:

try:
    myValue = response.body.something_else.my_value
except AttributeError:
    myValue = "default"

I guess using a block is maybe not at shwoopy as one quick line, like above.

[Samuel]

What about...

const value = (() => {
 try {
   return object.x.y
 } catch (err) {
   return 'default'
 }
})()

Easy as that... cough

[Samuel]

I mean, we could also do this (to get rid of the IIFE), but that's unfunctional, and I don't wanna use a let tbh.

let value
try {
  value = object.x.y
} catch (err) {
  value = 'default'
}

Another option would probably be this, but ew, async where we don't need it...

const value = await new Promise(resolve => resolve(object.x.y))
  .catch(err => 'default')

So yeah, maybe we do need this new operator, although I really am worried about handling probably-invalid data structures. I mean, isn't that an indicator we should probably write our code a different way? Maybe we should, for example, use another function to handle that specific input, which should be checked before that? I don't know, just speculating.

[K]

yes, like I said model your data right and things get more robust.

The promis catching is nice and I prefer it, but sometimes await is nicer in a specific case and you have to try-catch, I guess ?. would be simpler then.

[K]

You're totally right. Somehow JS devs aren't too fond of try-catch, guess it's like you said: too explicit?

Maybe it has also to do with the async nature of JS code, you simply couldn't catch them callbacks, so many people didn't use it too often.

[Ryan Palo]

Ooh that makes sense. Cool, thanks!

[JavaScript Joel]

I have been told "Avoid using exceptions for control flow". If you know something might throw an exception and you can check for it, do that instead.

A try block is also greedy and you may end up swallowing more than what you were hoping for, which can be a PITA for chasing down odd errors.

[K]

Yeh, in statically typed languages you can at least easily filter what you wanna catch :/

[Mark]

isn't that why you now have promises and the .catch() there?

[K]

sure, but you're not always inside a promise

[Nomæd]

Try-Catch aren't popular in JS because engines can't optimize the code well, or something of this sort that I read somewhere a while ago. I use Try-Catch with promises quite often.

[K]

I read that's the case for many languages.

[Michiel Hendriks]

Exceptions are generally really expensive. Actual usage of them should be an exceptional case.