# \[RCR\] Thread.abort\_on\_exception default to true **URL:** \ **Category:** ruby-talk\ **Created:** [20 July 2009 21:19 UTC](https://rubytalk.org/t/rcr-thread-abort-on-exception-default-to-true/54500 "2009-07-20T21:19:55Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Roger\_Pack4](https://avatars.discourse-cdn.com/v4/letter/r/bb73d2/32.png) [@Roger\_Pack4](https://rubytalk.org/u/Roger_Pack4)\ **Post date:** [20 July 2009 21:19 UTC](https://rubytalk.org/t/rcr-thread-abort-on-exception-default-to-true/54500/1 "2009-07-20T21:19:55Z")
Background: currently if you have a thread that "dies" without being cleaned up Thread.new { raise 'you never see this message' } sleep The error messages are basically swallowed, which I always find surprising--they aren't for the main thread but they are for internal threads. RCR is to default to abort\_on\_exception to true. Thoughts? =r > **···** > > -- > Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/). ---
**Author:** ![Yukihiro\_Matsumoto2](https://avatars.discourse-cdn.com/v4/letter/y/b9e5f3/32.png) [@Yukihiro\_Matsumoto2](https://rubytalk.org/u/Yukihiro_Matsumoto2)\ **Post date:** [20 July 2009 21:30 UTC](https://rubytalk.org/t/rcr-thread-abort-on-exception-default-to-true/54500/2 "2009-07-20T21:30:04Z")
Hi, > **···** > > In message "Re: [RCR] Thread.abort\_on\_exception default to true" on Tue, 21 Jul 2009 06:19:55 +0900, Roger Pack \ writes: > > > Background: > > currently if you have a thread that "dies" without being cleaned up > > What do you mean by "clean up" here? If you care about the thread > status, you can call join, that reports the exception inside of the > thread. > >               matz. ---
**Author:** ![Roger\_Pack4](https://avatars.discourse-cdn.com/v4/letter/r/bb73d2/32.png) [@Roger\_Pack4](https://rubytalk.org/u/Roger_Pack4)\ **Post date:** [20 July 2009 21:45 UTC](https://rubytalk.org/t/rcr-thread-abort-on-exception-default-to-true/54500/3 "2009-07-20T21:45:03Z")
> What do you mean by "clean up" here? If you care about the thread > status, you can call join, that reports the exception inside of the > thread. I agree that using #join here would result in cleanup that would allow the exception to no longer be swallowed--however I will explain my side of it. Typically one uses join to mean only "wait for termination"--using it as cleanup has always felt surprising to me, and whenever I start a new multi-thread application, I am almost always surprised by the fact that some error messages are swallowed. here's a (somewhat contrived) ex: "deep within a some server: " Thread.new { send an email } # continue running, handle next request, etc. In this instance, I don't want to join on the thread because I am not concerned about when it finishes--it doesn't matter to me, and I don't want to wait for it as it would slow up processing my next request. Therefore the exception is forgotten. I only mention it because this just happened to me (again--this time while debugging someone else's code, but), it surprised me once more, hence my noting it here--perhaps as a compromise threads could output the uncaught backtrace to stderr unless #join has already been called on the thread? I realize there are problems with that, too, just thinking for options. Thoughts? Thanks. =r > **···** > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Joel\_VanderWerf1](https://avatars.discourse-cdn.com/v4/letter/j/94ad74/32.png) [@Joel\_VanderWerf1](https://rubytalk.org/u/Joel_VanderWerf1)\ **Post date:** [20 July 2009 21:52 UTC](https://rubytalk.org/t/rcr-thread-abort-on-exception-default-to-true/54500/4 "2009-07-20T21:52:54Z")
Yukihiro Matsumoto wrote: > Hi, > > \>Background: > \>currently if you have a thread that "dies" without being cleaned up > > What do you mean by "clean up" here? If you care about the thread > status, you can call join, that reports the exception inside of the > thread. If you don't know when a thread will finish, it's hard to know when to call join. I'm not arguing for the RCR, though. The default makes sense to me--one poorly-rescued thread won't take down the process. Still, I don't see an easy way for a master thread to wait for worker threads to finish and report their results as soon as they are available. The alternatives: 1. thread.each {|t| t.join} # blocks on first running thread 2. polling 3. queues Maybe if there were a ThreadGroup#wait or something... > **···** > > > In message "Re: [RCR] Thread.abort\_on\_exception default to true" \> on Tue, 21 Jul 2009 06:19:55 +0900, Roger Pack \ writes: > > -- >        vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407 ---
**Author:** ![Justin\_Collins](https://avatars.discourse-cdn.com/v4/letter/j/3e96dc/32.png) [@Justin\_Collins](https://rubytalk.org/u/Justin_Collins)\ **Post date:** [21 July 2009 00:13 UTC](https://rubytalk.org/t/rcr-thread-abort-on-exception-default-to-true/54500/5 "2009-07-21T00:13:31Z")
Joel VanderWerf wrote: > Yukihiro Matsumoto wrote: > > > Hi, > > > > \>Background: > > \>currently if you have a thread that "dies" without being cleaned up > > > > What do you mean by "clean up" here? If you care about the thread > > status, you can call join, that reports the exception inside of the > > thread. > > If you don't know when a thread will finish, it's hard to know when to call join. I'm not arguing for the RCR, though. The default makes sense to me--one poorly-rescued thread won't take down the process. > > Still, I don't see an easy way for a master thread to wait for worker threads to finish and report their results as soon as they are available. The alternatives: > > 1. thread.each {|t| t.join} # blocks on first running thread > > 2. polling > > 3. queues > > Maybe if there were a ThreadGroup#wait or something... There is ThreadsWait#all\_waits which can execute a block as each thread ends, and there is ThreadsWait#next\_wait which returns the next thread that terminates. [http://ruby-doc.org/stdlib/libdoc/thwait/rdoc/classes/ThreadsWait.html](http://ruby-doc.org/stdlib/libdoc/thwait/rdoc/classes/ThreadsWait.html) -Justin > **···** > > > > In message "Re: [RCR] Thread.abort\_on\_exception default to true" \>\> on Tue, 21 Jul 2009 06:19:55 +0900, Roger Pack \>\> \ writes: ---
**Author:** ![Yukihiro\_Matsumoto2](https://avatars.discourse-cdn.com/v4/letter/y/b9e5f3/32.png) [@Yukihiro\_Matsumoto2](https://rubytalk.org/u/Yukihiro_Matsumoto2)\ **Post date:** [21 July 2009 00:49 UTC](https://rubytalk.org/t/rcr-thread-abort-on-exception-default-to-true/54500/6 "2009-07-21T00:49:35Z")
Hi, > here's a (somewhat contrived) ex: > > "deep within a some server: " > > Thread.new { send an email } > > # continue running, handle next request, etc. > > In this instance, I don't want to join on the thread because I am not > concerned about when it finishes--it doesn't matter to me, and I don't > want to wait for it as it would slow up processing my next request. > Therefore the exception is forgotten. I think you'd better handle the exception in the thread block. abort\_on\_exception means asynchronous exceptions will be delivered to the main thread. That means any exception may happen on any point in the main thread. From my point of view, asynchronous exception is like a nightmare, especially for production code. Most code is not exception safe at that level. That is the reason abort\_on\_exception to be false by default. That is only for debugging purpose.               matz. > **···** > > In message "Re: Thread.abort\_on\_exception default to true" on Tue, 21 Jul 2009 06:45:03 +0900, Roger Pack \ writes: ---
**Author:** ![Brian\_Candler](https://avatars.discourse-cdn.com/v4/letter/b/5f9b8f/32.png) [@Brian\_Candler](https://rubytalk.org/u/Brian_Candler)\ **Post date:** [21 July 2009 13:45 UTC](https://rubytalk.org/t/rcr-thread-abort-on-exception-default-to-true/54500/7 "2009-07-21T13:45:00Z")
Roger Pack wrote: > In this instance, I don't want to join on the thread because I am not > concerned about when it finishes--it doesn't matter to me, and I don't > want to wait for it as it would slow up processing my next request. > Therefore the exception is forgotten. You don't care if or when it finishes, but you also don't mind if it crashes your main program by raising an asynchronous exception? > **···** > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Joel\_VanderWerf1](https://avatars.discourse-cdn.com/v4/letter/j/94ad74/32.png) [@Joel\_VanderWerf1](https://rubytalk.org/u/Joel_VanderWerf1)\ **Post date:** [21 July 2009 03:15 UTC](https://rubytalk.org/t/rcr-thread-abort-on-exception-default-to-true/54500/8 "2009-07-21T03:15:24Z")
Justin Collins wrote: > There is ThreadsWait#all\_waits which can execute a block as each thread ends, and there is ThreadsWait#next\_wait which returns the next thread that terminates. > > [http://ruby-doc.org/stdlib/libdoc/thwait/rdoc/classes/ThreadsWait.html](http://ruby-doc.org/stdlib/libdoc/thwait/rdoc/classes/ThreadsWait.html) Yep, that's what I was looking for. Thanks! > **···** > > -- >        vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407 ---
**Author:** ![Roger\_Pack4](https://avatars.discourse-cdn.com/v4/letter/r/bb73d2/32.png) [@Roger\_Pack4](https://rubytalk.org/u/Roger_Pack4)\ **Post date:** [21 July 2009 15:00 UTC](https://rubytalk.org/t/rcr-thread-abort-on-exception-default-to-true/54500/9 "2009-07-21T15:00:03Z")
> abort\_on\_exception means asynchronous exceptions will be delivered to > the main thread. That means any exception may happen on any point in > the main thread. From my point of view, asynchronous exception is > like a nightmare, especially for production code. Most code is not > exception safe at that level. That is the reason abort\_on\_exception > to be false by default. That is only for debugging purpose. Hmm. True (I've even thought before that Thread#raise should be deprecated--too dangerous, can interrupt code in a finally block, etc). That being said, could it perhaps at least output something to stderr by default to satisfy both cases? Thanks. -=r > **···** > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Yukihiro\_Matsumoto2](https://avatars.discourse-cdn.com/v4/letter/y/b9e5f3/32.png) [@Yukihiro\_Matsumoto2](https://rubytalk.org/u/Yukihiro_Matsumoto2)\ **Post date:** [21 July 2009 15:12 UTC](https://rubytalk.org/t/rcr-thread-abort-on-exception-default-to-true/54500/10 "2009-07-21T15:12:16Z")
Hi, > **···** > > In message "Re: Thread.abort\_on\_exception default to true" on Wed, 22 Jul 2009 00:00:03 +0900, Roger Pack \ writes: > > > That being said, could it perhaps at least output something to stderr by > > default to satisfy both cases? > > Something to stderr is only useful in debugging, but no good for > production code. When debugging, put -d to the command line options. > It automatically enable abort\_on\_exception. > >               matz. ---
**Author:** ![Roger\_Pack4](https://avatars.discourse-cdn.com/v4/letter/r/bb73d2/32.png) [@Roger\_Pack4](https://rubytalk.org/u/Roger_Pack4)\ **Post date:** [21 July 2009 15:56 UTC](https://rubytalk.org/t/rcr-thread-abort-on-exception-default-to-true/54500/11 "2009-07-21T15:56:19Z")
> Something to stderr is only useful in debugging, but no good for > production code. When debugging, put -d to the command line options. > It automatically enable abort\_on\_exception. Sounds good. I suppose the -d option is underused by most people including myself. =r > **···** > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C).