react-router eats stack traces in willTransitionTo (and subsequently component*Mount)

[AndrewRayCode]

A frustrating behavior of the router:

https://github.com/rackt/react-router/blob/master/modules/Transition.js#L60

If you have any errors in your component mounting / instantiating, they are eaten by the router. All you'll get in the console is something like "Undefined is not a function" but no stack trace. I believe this is because the mount* functions get called synchronously, so when that code calls callback it triggers the React land component stuff, and any errors are caught by the try catch. The error eventually gets thrown here:

https://github.com/rackt/react-router/blob/e0a15ebc81d76119935fef27e0ab7d7b024b98fd/modules/createRouter.js#L303

This makes it very hard to debug errors in component instantiation.

This can be reproduced very simply by making a component with a willTransitionTo that has a runtime error either in the willTransitionTo or in the render.

[AndrewRayCode]

Update to this issue, it's something that was introduced in 0.12.x it appears.

The initial bug report above is slightly incorrect. I wasn't seeing a stack trace because I was calling Routes.run inside of a promise. However, you can still see the stack trace originating from the wrong place, making debugging difficult, in this JSFiddle: http://jsfiddle.net/qn68sdg6/8/

[chollier]

I've seen the same issue since I update to 0.12 as well

[AndrewRayCode]

Two undesirable workarounds:

1. For debugging, you can manually edit node_modules/react-router/modules/Transition.js and comment out the try / catch lines.
2. You can downgrade to 0.11.x, as long as you aren't using transition.wait : "react-router": "0.11.6", which does not have this behavior

[johanneslumpe]

@delvarworld here is a more desirable fix: http://jsfiddle.net/qn68sdg6/10/

Pass a custom onError method when you are creating the router, and then just re-throw the error. You should see a full stack trace in your console.

[jeffutter]

I think this may be the same issue I was experiencing here: #935

[johanneslumpe]

@jeffutter yeah seems like it. Sorry, didn't see your issue. But the same solution should apply :)

[jquense]

@johanneslumpe does that work? the onError in your workaround is the default value of onError https://github.com/rackt/react-router/blob/e0a15ebc81d76119935fef27e0ab7d7b024b98fd/modules/createRouter.js#L301

[johanneslumpe]

Yeah is the same. But it does give you a full stack trace - I'm not sure about the logic behind this though and why it behaves differently. ;)

On 12 Mar 2015, at 17:42, Jason Quense notifications@github.com wrote:

@johanneslumpe does that work? the onError in your workaround is the default value of onError https://github.com/rackt/react-router/blob/e0a15ebc81d76119935fef27e0ab7d7b024b98fd/modules/createRouter.js#L301

—
Reply to this email directly or view it on GitHub.

[johanneslumpe]

Actually I assume that the difference is that I am defining the callback outside of the component, so the scope is different. But that's just a wild guess.

[gaearon]

I'm a bit confused, won't “Pause on All Exceptions” work in this case?

[agundermann]

I guess so, but that seems like a bad excuse 😄

The way I see it, there are two problems:

1. When using transition hooks, the whole routing process afterwards (including run callback and synchronous render calls) will be wrapped within the try catch block of Transition.js. See Transition hooks error handling #981
2. Some browsers seem to have trouble reporting rethrown errors (e.g. only pointing to the line the error was rethrown, instead of showing the original stack trace). Possibly related to https://code.google.com/p/chromium/issues/detail?id=432516

We should be able to fix 1), but I'm not sure what to do about 2).

[ryanflorence]

;_;

we need to fix this, I can't think of anything in programming that aggravates me more than stuff like this. It's got to give you a stack trace with the real line of code that has the problem.

[jeffutter]

Any movement on this?