Using try-catch to retrieve the value of nested property. Is it an valid approach?

Question

We have an object (referenced by data) and we want to retrieve the value of a nested property. Ideally, we would like to do it like so:

value = data.category3.section2.article4.title;

We cannot do this like so, because the above line throws a reference error if any of the mediate objects (category3, section2, or article4) are not defined (at the corresponding positions) inside the data object.

---

Now, to nullify any potential reference errors that might be thrown, we could just place the above line inside a try-catch statement:

try {
    value = data.category3.section2.article4.title;
} catch (err ) {}

This works! However, I am not confident that relying on try-catch in such a way is a good practice. The alternative solution would be to manually traverse to the desired property value. I have written a compact utility function that accomplishes that:

function get( val, names ) {
    names = names.split( '.' );    
    while ( val && names.length ) { val = val[ names.shift() ]; }    
    return val;
}

Now we can get the property value like so

value = get( data, 'category3.section2.article4.title' );

---

So, my question is:

Is the try-catch approach a valid solution? Or are there valid reasons why it should be avoided?

Btw, the try-catch approach is heavily biased in this thread: What's the simplest approach to check existence of deeply-nested object property in JavaScript?

Answer 1

Why not:

var value = data && 
    data.category3 && 
    data.category3.section2 && 
    data.category3.section2.article4 && 
    data.category3.section2.article4.title;

That is safe (if any of the objects in the traversal chain are not set, value will be null). That is a little neater than a bunch of if blocks, and avoids (?mis)using exceptions.

Another use of that method to provide a default value on failure:

var value = data && 
    data.category3 && 
    data.category3.section2 && 
    data.category3.section2.article4 && 
    data.category3.section2.article4.title || 'default value';

Answer 2

Both are fine. The only major differences between them I can think of are that

1. The try-catch may cause a debugger to unecessarily halt too often if you tell it to stop on all exceptions.

   This is relevant you need to debug code that is swallowing exceptions. For example, some promise libraries wrap all callbacks in a try-catch block.

2. The string splitting version can't easily cope with properties that contain a dot in them

   var x = {'.': {a: 17}};
   try{ obj['.'].a }catch(e){}
   get(/*???*/)
   

---

If you want something robust that avoids both pitfalls I would suggest a function that can (at least optionally) directly receive a list of properties.

get(val, ['prop1', 0, '.', 'category2']);

Answer 3

I think the differences here are going to be mostly contextual - it depends on the data you're trying to access and what you want to do with it.

For example, the second function will return equivalent undefined values for a variety of circumstances, including both data.category3 === undefined and data.category3.section2.article4.title === undefined. Using try/catch here tells you that you have an actual traversal error, rather than a property that hasn't been set, which you might want to handle differently.

Answer 4

I have seen the answers here and I think that the traversing is your best move, but it looks quite bothersome. You can make a function that traverses it for you or you can use the almighty brototype library found at: https://github.com/letsgetrandy/brototype

This way you can do something like this:

if (Bro(data).doYouEven('category3.section2.article4.title')) {
    value = data.category3.section2.article4.title;
}

or you can use a callback:

Bro(app).iDontAlways('category3.section2.article4.title')
    .butWhenIdo(function(title){
        value = title;
    });

I think everyone should check this amazing library out, and code with great bro-ness.

If you dislike the brototype, you can indeed use your own get function.

Answer 5

Abusing try catch like this is a dirty hack.

Try catch is there to catch exceptions you throw. Exceptions are used for exceptional cases.

In this case both cases are wrong. You should never have to traverse data.category3.section2.article4.title; where every step can fail.

You should simply be able to assert that if data has a category then it should have a section, article and title.

I say refactor the code so you don't have multiple levels that can fail.