Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Disable try-catch for an individual test #357

doberkofler opened this Issue · 7 comments

3 participants


It would be helpful to disable the try-catch logic for an individual test and not only for all tests in the given markup.


What's your usecase for that?


I'm trying to implements tests using a custom window.onerror handler and would need to have certain exceptions being handled by to top lever error handler.


Are you testing the cross-browser behaviour of window.onerror itself? Or does that just happen to be how you handle the exceptions?

Assuming the latter, I recommend you abstract your handler so that it can be called directly from the unit test.

window.onerror = function (a, b, c) {
  APP.debug.handleGobal(a, b, c);

QUnit.test(..., 1, function (assert) {
  try {
  } catch (e) {
    assert.strictEqual(APP.debug.handleGlobal(..), .., ..);

That way you're testing individual units, instead of performing a full-on integration test which likely doesn't help very much to find the cause when it fails.


@doberkofler does Krinkle's suggestion work for you?


@Krinkle I'm trying to test a custom window.onerror handler that is supposed to store front-end error messages in the backend. To do this is would need to disable the try-catch logic in QUnit to have all exceptions land in the onerror handler itself. The custom onerror handler used in QUnit is quite easy to save and restore but I've not found a way to disbale the try-catch handling in QUnit.

I've just came up with a working but pretty complex solution (as always when thing get messy) using an iframe that actually mimics the behavior to be tested without using QUnit and then simply reporting back the results to the parent window where QUnit runs and perform the assertions.

I think it would be helpful to have an option allowing to disable the try-catch handler in QUnit.


@doberkofler that sounds like you could just go ahead and disable the try-catch handler for all tests. Or structure your tests so that those that need to go without it run in their own suite.

We currently don't have a generic API for test-specific configuration (expect and stop/start can't be reused), so adding support for this is far from trivial. That's why I'm hoping that workarounds will do the trick.


I don't think this one very special usecase justifies the added complexity.

@jzaefferer jzaefferer closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.