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
When callback exceptions are supressed, if an Input
or State
references an ID that doesn't exist at callback trigger, then an front-end exception is thrown
#57
Comments
More details: when E.g.,
-->
This exception would be raised if a user includes a callback using an For example, an exception is raised in this example:
because the second callback has an To fix this, a user may specify Doing this, however, puts you in debugging hell for large applications since any time you include a callback which has 1. an |
State
is referencing an ID that doesn't exist, then an front-end exception is thrownapp.config['suppress_callback_exceptions'] = True
, if a Input
or State
in a callback is referencing an ID that doesn't exist when the callback is triggered, then an front-end exception is thrown
app.config['suppress_callback_exceptions'] = True
, if a Input
or State
in a callback is referencing an ID that doesn't exist when the callback is triggered, then an front-end exception is thrownInput
or State
in a callback is referencing an ID that doesn't exist when the callback is triggered, then an front-end exception is thrown
Input
or State
in a callback is referencing an ID that doesn't exist when the callback is triggered, then an front-end exception is thrownInput
or State
references an ID that doesn't exist at callback trigger, then an front-end exception is thrown
It does not look like It appears that the exception is thrown from here. I think the quickest patch right now is just to throw a 'nice' exception there telling the user the bad id and the set of currently available ids. |
Yeah, a good exception would go a long way for me. Ultimately, I think that our solution will have to be propogating these error messages from the JS context up to the browser context (in dev-mode) with some type of persistent notifications. That's a much larger project that we should probably discuss in a separate issue |
Sounds good, I'll make a quick fix with a better exception for now |
Hello, I am currently working on a Dash project and came across the same issue, and completely understand why suppressing the warning is bad practise. I followed the thread attached at the end of page (A proposed alternative ...) but didn't really understand it. What is the proposed solution? Thanks in advance!! |
No description provided.
The text was updated successfully, but these errors were encountered: