-
Notifications
You must be signed in to change notification settings - Fork 51
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
fancylogger raiseException support templaiting via args #233
Comments
@JensTimmerman toughts? |
personally I would want to remove the raiseException call alltogether. it's not the loggers work to raise exceptions, only to log them. |
I ran into this issue and I agree with @JensTimmerman on this. We should deprecate raiseException and start logging deprecation warnings. |
if we don't deprecate it, it should work like all logger functions. the quick example is:
|
@wdpypere the problem is that people will only raise the exception (which doesn't support the lazy passing of args), and not log, and this makes most of the exceptions problematic to debug. |
I see the issue, but there is nothing preventing users from doing but then raiseException should at least work as all the other logging functions. I'll have a go at it. |
looking at it, its (as expected) a quite complex problem. As I can see in our code there are 2 main uses for raiseException:
If we really want to maintain a hybrid error/log thing I would do the same as python itself does it. logging.exception is no more than:
we could do that with an extra raise included, but that solution would only work for case 1, not for case 2. |
i wouldn't spend too much time on it but i'm ok with deprecating it. |
raiseException("%s %s", "a", "b", Exception)
should do the right thingThe text was updated successfully, but these errors were encountered: