When does a javascript error break the rest of the code?

Question

I've noticed sometimes that one javascript error will break other unrelated javascript functionality and sometimes it doesn't. I couldn't see a pattern in it and this makes debugging difficult (especially when you take on an old project and you don't have time to fix all errors).

For example this code:

$(".div-one").slick({ // settings for slick plugin });

Was breaking this code:

$('.product-options').click(function() {
    $('.message').slideToggle('show');
});

when there was no .div-one element on the page. It retuned an element undefined error. so I wrapped it in an if statement checking for the length of .div-one and now the code works fine.

But obviously there are lots of cases when javascripts error do not break anything.

So when will js error cause problems? The 2 pieces of code were in the same file. Maybe it affects only same file?

Thanks!

Not a full answer as I don't have time to back this up, but in my experience it tends to be linear, possibly within a given scope. If line 47 had an error, line 50 will be affected... — StackExchange What The Heck, Aug 28 '15 at 08:33

score 17 · Accepted Answer · answered Aug 28 '15 at 08:35

JavaScript is no different from other languages with exceptions in this regard.

If you have:

doThis();
doThat();
doSomethingElse();

...and doThat throws an exception, the code after it (doSomethingElse, in this case) is never run (in all languages with exceptions, including JavaScript).

So if you have:

$(".div-one").slick({ /* settings for slick plugin */ });

$('.product-options').click(function() {
    $('.message').slideToggle('show');
});

...and the call to slick throws an exception, the click handler below it will never get hooked up, because that code doesn't run.

In contrast, if slick doesn't throw an exception, but later when you use whatever the slick functionality is and it fails, that won't affect the click handler, because that failure didn't prevent the click handler from getting hooked up.

As with other languages with exceptions, you can control the impact of exceptions; in the case of JavaScript (and several others), you do that with try/catch (and optionally finally) blocks, e.g.:

try {
    $(".div-one").slick({ /* settings for slick plugin */ });
} catch (e) {
    // Some appropriate handling of the exception
}
try {
    $('.product-options').click(function() {
        $('.message').slideToggle('show');
    });
} catch (e) {
    // Some appropriate handling of the exception
}

There, an exception calling slick doesn't prevent the click handler from being hooked up.

You always have a way of rocking ! :) – elad.chen Aug 28 '15 at 08:39 — elad.chen, Aug 28 '15 at 08:39

score 1 · Answer 2 · answered Aug 28 '15 at 08:37

This is because the author of the $.fn.slick plugin didn't account for empty results set passed by jQuery chaining API.

It is quite possible that the author opted to throw an exception. By doing so, A developer can be quickly notified why the plugin isn't behaving as it should.

Think about it, what will happen if you passed an incorrect selector:

$("div-one") instead of $(".div-one")

Would you prefer it to fail silently by doing nothing, or would prefer to be notified ( brutally ) by a stop in execution of everything that follows?

indeed, would prefer the later one, too bad it is not used as much. — Claudiu Creanga, Aug 28 '15 at 08:50

When does a javascript error break the rest of the code?

2 Answers2

Linked