Closed CastixGitHub closed 6 years ago
before_validate
is surely the wrong place where to trap this (what does it have to do checking pluggable with validating a controller parameters?)
If a pluggable fails there should be some kind of error during startup
hook.
Also by https://github.com/TurboGears/tgext.pluggable/blob/master/tgext/pluggable/plug.py#L77 it looks like it's explicitly wanted that the application doesn't crash when it failed to plug a single pluggable.
I used before_validate
just because it's currentely the first hook called when a request starts, now i changed it with before_call
, thanks for the suggestion. about reraising the exception, i noticed it and I'm finding a way to preserve the stacktrace, altough I get some errors doing
raise sys.exc_info()[0], sys.exc_info()[1], sys.exc_info()[2]
TypeError: exceptions must be old-style classes or derived from BaseException, not NoneType
or
raise sys.exc_info[0], sys.exc_info[1], sys.exc_info[2]
TypeError: 'builtin_function_or_method' object has no attribute '__getitem__'
or
raise Exception(sys.exc_info()[0], sys.exc_info()[1], sys.exc_info()[2])
Exception: (None, None, None)
got it, the hook is ran in an other thread, so
_e = sys.exc_info()[0], sys.exc_info()[1], sys.exc_info()[2]
def fail_if_failed_to_plug(remainder, params):
raise _e
is enough. but, how can I let Backlash (or the Werkzeug Debugger) show the exception nicely? the exception does have the right traceback but it seems that the debugger takes information about where the exception is raised
I don't get the relation with backlash, It's something that fails during application startup not while the application is running. Backlash is involved in showing that you had an error while the application is running, but when there is an error during application startup the application should just not start. Not start and then throw errors during validation
crash loudly if a pluggable fails to being plugged, before that you would get cryptic errors all aroud, now the whole application stops