3

Consider a hypothetical example : 

var r = function (o) { 
    try { o.a.b } 
    catch (e){} 
};

var o={};

r(o.a.b);

console.log('aaaa');

//TypeError: o.a is undefined

Is there a way to handle this kind of error and displaying "aaaa" nevertheless? Or is this what being called an "uncaught typeerror" that seems to always lead to fail?

Ty for the link, but it was not really the same question that the one mentionned above. I have my own way to test for nested object, my question was more on how it is possible in javascript to handle Type Error outside of the execution process, without disturbing this one, i.e. returning false and that's all. As pointed per Pointy \o/ that is not a possible really, and this is the answer I guess.

Guillaume Fe
  • 369
  • 4
  • 16
  • 1
    You have a `try ... catch` inside your function, but you *don't* have a `try ... catch` when you refer to `o.a.b` *outside* the function. See what happens if you just call with the whole empty object: `r(o)` – Pointy Mar 02 '16 at 14:59
  • that's a point. Is there a wat as far as you know to send the whole context to the function without automatically being evaled between the parenthesis? I mean not by sending arguments separetely for a further check by r(), nor even using JSON.stringiify inside the parenthessis but by making a handler tnat can transparency remove this kind of error elsewhere – Guillaume Fe Mar 02 '16 at 15:00
  • No, there is not. An expression is an expression, and function argument expressions are evaluated before the function is called. – Pointy Mar 02 '16 at 15:02
  • 2
    If you would elaborate on the larger problem you're trying to solve, you might get some useful advice. – Pointy Mar 02 '16 at 15:03
  • a ok, no no big probleme, just trying to hack a bit into my favorite langage, ty – Guillaume Fe Mar 02 '16 at 15:03

1 Answers1

2

You can use:

if(o.a) {
    r(o.a.b);
} else {
    //handle error
}
console.log('aaaa');

to check if the properties exists. And if you need to check that o.a.b exists too, just extend the if:

if(o.a && o.a.b) {
    r(o.a.b);
} else {
    //handle error
}
console.log('aaaa');

These ifs are checking for existence, but will also flag up for false values - so if o.a or o.a.b are false, the check will fail

millerbr
  • 2,951
  • 1
  • 14
  • 25
  • if `a.o` or `a.o.b` false you may have a problem. safer to use `typeof`. – I wrestled a bear once. Mar 02 '16 at 15:04
  • @Pamblam: He doesn't have a problem if `o.a` is falsey but if `o.a.b` is, it could be an issue. The `typeof` operator isn't needed though. He should just drop the `&& o.a.b`, or in the case of the function parameter, `if (o && o.a) {...` –  Mar 02 '16 at 15:07
  • Thanks for the advice guys - I'd actually added the second check in because I was unsure whether it was needed! It's been removed – millerbr Mar 02 '16 at 15:12
  • @squint - i don't follow.. why are you suggesting he not check for the `b` property? if it doesn't exist he'll be passing undefined to the function and then there will be a new problem.. – I wrestled a bear once. Mar 02 '16 at 15:12
  • lol.. @millerbr, now you're back to your original problem.. the correct solution is `if(o.a && typeof o.a.b != 'undefined'){...}` – I wrestled a bear once. Mar 02 '16 at 15:16
  • yep millerbr the second one is the best alternative i know as well (and that works for sure, both and everything works since IF is evaling things one after another) – Guillaume Fe Mar 02 '16 at 15:18
  • @Pamblam: I think the example seems a little messed up since he's checking the same property nesting both in and out of the function. If outside, he already knows `o` is an object, so he can just do `o.a && o.a.b`. Inside, he doesn't know what will be received, so he would need `o && o.a && o.a.b`. Using `typeof` like that is not at all needed. If he wanted any value except `undefined`, he could do `if (o.a && o.a.b !== undefined)`, though `null` would still get through, so he could use `!=` instead of `!==`. –  Mar 02 '16 at 15:41
  • @squint - ok, i get what you're saying now. except `undefined` is undefined, so he would have to use `typeof` :p ... unless he does one of these `(function(undefined){ /* codes here */ })();` – I wrestled a bear once. Mar 02 '16 at 16:11
  • so in other words `the correct solution is if(o.a && typeof o.a.b != 'undefined'){...}` :P – I wrestled a bear once. Mar 02 '16 at 16:20
  • @Pamblam: Why is `undefined` undefined? It's a read-only global identifier. Old browsers could re-define it, but that never really happened even back then, and if it did, was soon discovered since code stopped working. The `typeof foo == "undefined"` is a clumsy hack that just isn't needed. –  Mar 02 '16 at 18:53
  • @squint - it's not any kind of identifier i've ever heard of. if you know something i don't know references would be appreciated. https://jsfiddle.net/z0L0a2f4/ – I wrestled a bear once. Mar 02 '16 at 19:12
  • @Pamblam: If you want sources, you can check the ECMAScript specification or MDN. Easier though to simply test like you would with any other global variable. `"undefined" in window; // true` I'm not understanding what the jsFiddle was supposed to show. From what I see, the `undefined` variable is indeed showing to have the `undefined` value. There's no need for `typeof` to check `undefined` in most code. –  Mar 02 '16 at 19:52
  • well that's embarrasing.. i didn't believe you.. was doing `var undefined = (function(u){ return u; }());` good to know – I wrestled a bear once. Mar 02 '16 at 23:13