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
Errors in config options can cause renderer to crash without notice #1593
Comments
The issue is this part of the code where the exception is ignored ( Then, this line in renderer could throw an exception if the config option fails to evaluate: |
I noticed the signal handler swallowing all exceptions (see #1451). I have changed the code to log an error on every exception. But I noticed that exceptions get thrown in quite a few places and not caught until the signal emitter does (not really optimal), will see what I can do about that. |
If any signal receiver throws an exception for any reason after receiving a signal, no one would find out about it because the signal emitter just ignored exceptions Also actually delivering the signal caused some exceptions because not all signals have a receiver. Resolves polybar#1593
Alright, wasn't that bad to fix. |
If any signal receiver throws an exception for any reason after receiving a signal, no one would find out about it because the signal emitter just ignored exceptions Also actually delivering the signal caused some exceptions because not all signals have a receiver. Resolves #1593
If any signal receiver throws an exception for any reason after receiving a signal, no one would find out about it because the signal emitter just ignored exceptions Also actually delivering the signal caused some exceptions because not all signals have a receiver. Resolves polybar#1593
Describe the issue
If you have an error in a config option that is accessed in the
renderer::renderer
component constructor, the renderer not be constructed and no feedback is given to the user (and because the renderer won't be constructed, no bar is drawn).Expected behavior:
There should be a clear error presented to the user about what is wrong and polybar should either exit or assume a reasonable default.
Actual behavior:
Polybar (the process) keeps running but no bar is visible.
Was it working before?
Haven't tested this (didn't experience it with my own configuration)
To Reproduce
A minimal but complete config with which the problem occurs:
Polybar Log
(The "EXCEPTION CAUGHT" and some other logs are printed by debug logging I patched into my polybar and is not actually there in master):
Environment:
polybar -vvv
:The text was updated successfully, but these errors were encountered: