[issue36666] threading.Thread should have way to catch an exception thrown within

[STINNER Victor]

STINNER Victor  added the comment:

I consider that this issue as a duplicate of bpo-1230540. Python 3.8 has a new 
threading.excepthook hook which can be used in various ways to decide how to 
handle uncatched thread exceptions.

https://docs.python.org/dev/library/threading.html#threading.excepthook

--
nosy: +vstinner
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Add threading.excepthook() to handle uncaught exceptions raised 
by Thread.run()

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36666] threading.Thread should have way to catch an exception thrown within

[Joel Croteau]

Joel Croteau  added the comment:

I'm kind of in agreement with Mark on this, actually. I came across this 
problem when examining some threaded code that was clearly not working as 
intended, but was reporting success. Figuring out why that was was not easy. 
The code had been hastily ported to a multi-threaded version from an iterative 
version by my predecessor, and neither of us had enough familiarity with Python 
threads to realize what the problem was. The whole point of having exceptions 
is that it gives you a way of knowing when errors happen without having to add 
a bunch of extra error checking to your own code. It rather defeats the purpose 
if code can silently fail while still throwing exceptions, and we have to add 
extra code to handle special cases like this where they are ignored.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36666] threading.Thread should have way to catch an exception thrown within

[Mark Borgerding]

Mark Borgerding  added the comment:

I'm not trying to disrespect anyone: not users nor certainly Python developers. 
 I have loved Python since I learned it in 2001.  I was merely trying to 
respond to what seemed like an automatic rejection of changing legacy behavior. 
 I certainly agree changes to default behavior should not be made lightly, but 
sometimes they *should* be made.

This may be such a case:
a) A user writing a thread function either consciously thinks about exceptions 
while they write function or they do not.  Sure, we should always do the 
former; just like we should always eat our veggies and get lots of exercise, 
but 
b) If they *do* think about exceptions, they will either
b.1) write exception handlers within that function, or
b.2) rely on default behavior that simply prints out the exception string to 
stderr and lets the thread quietly die.
c) If they did not explicitly think about exceptions while they wrote the 
function, they may have in the back of their mind the reasonable expectation 
that an exception will not be ignored.

Changing `join()` to propagate unhandled exceptions would admittedly break b.2 
code, but provides absolution for all sinners who have written case c.

This is what I meant by, "I suspect there is more code that will be fixed by 
such a change than broken."

I'll confess I only just now became aware of `threading.excepthook` added in 
python 3.8.  Does it change this problem?

--
Added file: https://bugs.python.org/file48686/ignored_thread_exc.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36666] threading.Thread should have way to catch an exception thrown within

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> I'd argue such code deserves to be broken

That argument falls flat with me and it doesn't show respect for our users.  
The proposal would be a major change to the "rules of the game" and would 
likely require discussion and buy-in on python-dev and perhaps a PEP.

Please heed Antoine's advice.  This is his area of expertise, and he has 
suggested a plausible way to go forward.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36666] threading.Thread should have way to catch an exception thrown within

[pmp-p]

Change by pmp-p :


--
nosy: +pmpp

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36666] threading.Thread should have way to catch an exception thrown within

[Mark Borgerding]

Mark Borgerding  added the comment:

@pitrou  I don't necessarily agree that "current behavior can't be changed". 
One major selling point of exceptions is that they cannot be accidentally 
ignored.  The exception is how the current threading.Thread ignores them.

You are correct that changing Thread.join() so it propagates exceptions by 
default may break code that relies on the implicit behavior of a thread dying 
when the target/run method raises.  I'd argue such code deserves to be broken 
-- "explicit is better than implicit".

I suspect there is more code that will be fixed by such a change than broken.

--
nosy: +Mark Borgerding

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36666] threading.Thread should have way to catch an exception thrown within

[Joel Croteau]

Joel Croteau  added the comment:

Yes, I know there are workarounds for it, I have seen many, and everyone seems 
to have their own version. I'm saying we shouldn't need workarounds though–this 
should be built in functionality. Ideally, dropping an exception should never 
be default behavior, but I understand not wanting to break existing code, 
that's why I'm saying add additional functionality to make these checks easier 
and not require hacky, un-pythonic wrappers and other methods to find out if 
your code actually worked.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36666] threading.Thread should have way to catch an exception thrown within

[Eric Snow]

Eric Snow  added the comment:

Here's a basic decorator along those lines, similar to one that I've used on 
occasion:

def as_thread(target):
def _target():
try:
t.result = target()
except Exception as exc:
t.failure = exc
t = threading.Thread(target=_target)
return t

Sure, it's border-line non-trivial, but I'd hardly call it "exceptionally 
complicated".

Variations for more flexibility:

def as_thread(target=None, **tkwds):
# A decorator to create a one-off thread from a function.
if target is None:
# Used as a decorator factory
return lambda target: as_thread(target, **tkwds)

def _target(*args, **kwargs):
try:
t.result = target(*args, **kwargs)
except Exception as exc:
t.failure = exc
t = threading.Thread(target=_target, **tkwds)
return t


def threaded(target, **tkwds):
# A decorator to produce a started thread when the "function" is called.
if target is None:
# Used as a decorator factory
return lambda target: as_thread(target, **tkwds)

@functools.wraps(target)
def wrapper(*targs, **tkwargs)
def _target(*args, *kwargs):
try:
t.result = target(*args, **kwargs)
except Exception as exc:
t.failure = exc
t = threading.Thread(target=_target, args=targs, kwargs=tkwargs, 
**tkwds)
t.start()
return t
return wrapper

--
nosy: +eric.snow

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36666] threading.Thread should have way to catch an exception thrown within

[Joel Croteau]

Joel Croteau  added the comment:

I agree that we should not change the default behavior of Thread.join(), as 
that would break existing code, but there are plenty of other ways to do this. 
I see a couple of possibilities:

1. Add an option to the Thread constructor, something like raise_exc, that 
defaults to False, but when set to True, causes join() to raise any exceptions.

2. (Better, IMO) Add this option to the join() method instead.

3. Create a new method, join_with_exc(), that acts like join() but raises 
exceptions from the target.

4. (Should probably do this anyway, regardless of what else we do) Add a new 
method, check_exc(), that checks if any unhandled exceptions have occurred in 
the thread and returns and/or raises any that have.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36666] threading.Thread should have way to catch an exception thrown within

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The current behavior can't be changed for compatibility reasons (imagine user 
programs starting to raise on Thread.join()), but we could add an option to the 
threading.Thread() constructor in order to store and propagate exceptions.

--
nosy: +giampaolo.rodola, pablogsal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36666] threading.Thread should have way to catch an exception thrown within

[Antoine Pitrou]

Change by Antoine Pitrou :


--
nosy: +tim.peters
type:  -> enhancement
versions: +Python 3.8 -Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36666] threading.Thread should have way to catch an exception thrown within

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36666] threading.Thread should have way to catch an exception thrown within

[Joel Croteau]

New submission from Joel Croteau :

This has been commented on numerous times by others 
(https://stackoverflow.com/questions/2829329/catch-a-threads-exception-in-the-caller-thread-in-python,
 http://benno.id.au/blog/2012/10/06/python-thread-exceptions, to name a few), 
but there is no in-built mechanism in threading to catch an unhandled exception 
thrown by a thread. The default behavior of dumping to stderr is completely 
useless for error handling in many scenarios. Solutions do exist, but I have 
yet to see one that is not exceptionally complicated. It seems like checking 
for exceptions should be a very basic part of any threading library. The 
simplest solution would be to just have the Thread store any unhandled 
exceptions and have them raised by Thread.join(). There could also be 
additional methods to check if exceptions were raised.

--
components: Library (Lib)
messages: 340520
nosy: Joel Croteau
priority: normal
severity: normal
status: open
title: threading.Thread should have way to catch an exception thrown within
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com