[issue34086] logging.Handler.handleError regressed in python3

Change by Vinay Sajip : -- resolution: -> not a bug stage: -> resolved status: open -> closed type: -> behavior ___ Python tracker ___ __

[issue34086] logging.Handler.handleError regressed in python3

Oren added the comment: You're right - I misread those examples, sorry about that. It looks like my former colleague may have invented the bad code in question. I'm ok with closing as "not a bug" - I do think not fixing it adds a small potential friction for people upgrading their version o

[issue34086] logging.Handler.handleError regressed in python3

Vinay Sajip added the comment: > Here's some evidence that this is true I'm not sure that's evidence. That example page you linked to has 4 instances of handleError: 2 are definitions of overrides, and the other two are calls to the superclass method from those overriding methods, which woul

[issue34086] logging.Handler.handleError regressed in python3

Oren added the comment: The code that was causing this problem looked something like: -- def emit(self, record): ... response = requests.post(...) if not response.ok: self.handleError(record) ... -- In this case, something does apparently go wrong, but it doesn't actually involv

[issue34086] logging.Handler.handleError regressed in python3

Vinay Sajip added the comment: For the crash to occur, it would have to be a handleError() called wrongly, when something didn't apparently go wrong (i.e. a call from outside an exception handling clause). So I'm not sure I follow your logic. I agree the change you propose is simple, but tha

[issue34086] logging.Handler.handleError regressed in python3

Oren added the comment: I totally agree that this involves misusing handleError. I ended up fixing the code that originally caused the problem, since it was wrong in the first place. The reason I filed this bug and that I think it's worth fixing is that in previous versions, the problem woul

[issue34086] logging.Handler.handleError regressed in python3

Vinay Sajip added the comment: It seems innocuous enough, but the documentation for handleError() does say: "This method should be called from handlers when an exception is encountered during an emit() call." That documentation is the same for 2.x and 3.x. This is not how you are using it.

[issue34086] logging.Handler.handleError regressed in python3

Change by Vinay Sajip : -- versions: -Python 3.4, Python 3.5 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34086] logging.Handler.handleError regressed in python3

Change by Oren : -- nosy: +vinay.sajip ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.or

[issue34086] logging.Handler.handleError regressed in python3

Oren added the comment: I realize that there is a legitimate argument that handleError() is being used wrong in the example, but since it used to work, it'd be nice if it still did. I came across this after converting a codebase to python3 and it took a while for this problem to appear. I

[issue34086] logging.Handler.handleError regressed in python3

New submission from Oren : In python2, calling Handler.handleError may not be strictly correct, but it doesn't raise an exception. However, this has regressed since this patch: https://hg.python.org/cpython/rev/d7b868cdd9bb $ cat logbug.py import logging class CustomHandler(logging.Handler):