Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Unhandled exception in the data loader does not print the stack trace to the console #10282

Closed
jdufresne opened this issue Mar 29, 2023 · 5 comments · Fixed by #10286
Closed
Labels

Comments

@jdufresne
Copy link
Contributor

What version of React Router are you using?

6.9.0

Steps to Reproduce

Use the example:

import React from "react";
import {
    createBrowserRouter,
    RouterProvider,
    useLoaderData,
} from "react-router-dom";

let router = createBrowserRouter([
    {
        path: "/",
        loader: homeLoader,
        element: <Home />,
    },
]);

export default function App() {
    return <RouterProvider router={router} />;
}

export async function homeLoader() {
    throw new Error('bug!')
    return {};
}

export function Home() {
    let data = useLoaderData() as HomeLoaderData;
    return <h2>Home</h2>;
}

In this example, there is a bug in homeLoader that throws an unhandled exception.

This exception causes the errorElement to render (good and expected) but the error itself is never printed to the JavaScript console using console.error or similar.

I consider this a bug as the docs say:

https://reactrouter.com/en/main/route/error-element

If you do not provide an errorElement in your route tree to handle a given error, errors will bubble up and be handled by a default errorElement which will print the error message and stack trace. Some folks have questioned why the stack trace shows up in production builds. Normally, you don't want to expose stack traces on your production sites for security reasons. However, this is more applicable to server-side errors (and Remix does indeed strip stack traces from server-side loader/action responses). In the case of client-side react-router-dom applications the code is already available in the browser anyway so any hiding is just security through obscurity. Furthermore, we would still want to expose the error in the console, so removing it from the UI display is still not hiding any information about the stack trace. Not showing it in the UI and not logging it to to the console would mean that application developers have no information at all about production bugs, which poses its own set of issues. So, again we recommend you always add a root level errorElement before deploying your site to production!

I understand this mean the error should be printed to the console. Errors that occur during rendering (instead of in the loader) do print to the console as expected.

Printing the error to the console would improve the developer experience for debugging and testing.

Expected Behavior

The unhandled error in the loader is printed to the JavaScript console with its stack trace.

Actual Behavior

The unhandled error does not appear not JavaScript console.

The errorComponent does render.

@jdufresne jdufresne added the bug label Mar 29, 2023
@brophdawg11
Copy link
Contributor

You're getting the stack in the UI (in dev mode) though right? You just also want it in the console for clickable source links?

@jdufresne
Copy link
Contributor Author

Yes, that is right. The stack renders inside the default errorElement, just not in the console.

@brophdawg11 brophdawg11 added the awaiting release This issue have been fixed and will be released soon label Apr 10, 2023
@brophdawg11 brophdawg11 self-assigned this Apr 10, 2023
@brophdawg11
Copy link
Contributor

brophdawg11 commented Apr 21, 2023

Fixed by #10286. This will be available when React Router 6.11 is released.

@brophdawg11 brophdawg11 removed their assignment Apr 21, 2023
@github-actions
Copy link
Contributor

🤖 Hello there,

We just published version 6.11.0-pre.0 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

@github-actions
Copy link
Contributor

🤖 Hello there,

We just published version 6.11.0 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

@brophdawg11 brophdawg11 removed the awaiting release This issue have been fixed and will be released soon label Apr 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants