From: "RRRoy BBBean" <rrroybbbean@...>
Date: 2017-10-28T18:55:23-05:00
Subject: [ruby-core:83598] Re: [Ruby trunk Feature#6647] Exceptions raised in threads should be logged

Maybe I don't understand this issue in sufficient detail, but...

 I routinely use Thread.abort_on_exception=true when I want an
exception in a worker thread to raise an error in the main thread of
execution. If I don't specify this, then the worker thread fails
silently. This is predictable behavior.

If the default (predictable) behavior were to change, then how much
legacy code would be affected? How much stuff would break?

On Sat, 2017-10-28 at 12:09 +0000, eregontp@gmail.com wrote:
> Issue #6647 has been updated by Eregon (Benoit Daloze).
> 
> 
> Eregon (Benoit Daloze) wrote:
> > FWIW, I enabled Thread.report_on_exception = true by default in
> > ruby/spec.
> > I had to change a few specs, but I think it really improved the
> > specs rather than being cumbersome.
> > See https://github.com/ruby/spec/pull/517 for details.
> 
> And it already proved useful!
> https://travis-ci.org/ruby/spec/jobs/294063354
> No way to know why we get ECONNREFUSED without seeing the other
> thread dying with EBADF.
> 
> akr:
> > So, I think we should try report-on-GC.
> 
> I don't think report-on-GC is good, it just shows the error too late,
> if it shows it at all.
> This is adding extra non-determinism on top of non-deterministic
> thread bugs, so I'm against it.
> 
> I argue that 99% of rubyists expect their threads to not die, or they
> plan for it and use Thread.new{begin ... rescue ... end} to
> log/handle exceptions.
> Who wants a part of the program crashing silently? Nobody.
> 
> Thread#join is often too late, and it is a tiny price to pay to use
> Thread.report_on_exception = false in the rare case of using short-
> lived threads with no exception handling except #join.
> Long-running threads are typically only joined at the end of the
> program, but the error, the fact that the thread died, should be
> shown to the programmer much earlier.
> 
> ----------------------------------------
> Feature #6647: Exceptions raised in threads should be logged
> https://bugs.ruby-lang.org/issues/6647#change-67623
> 
> * Author: headius (Charles Nutter)
> * Status: Closed
> * Priority: Normal
> * Assignee: matz (Yukihiro Matsumoto)
> * Target version:��
> ----------------------------------------
> Many applications and users I have dealt with have run into bugs due
> to Ruby's behavior of quietly swallowing exceptions raised in
> threads. I believe this is a bug, and threads should always at least
> log exceptions that bubble all the way out and terminate them.
> 
> The implementation should be simple, but I'm not yet familiar enough
> with the MRI codebase to provide a patch. The exception logging
> should be logged in the same way top-level exceptions get logged, but
> perhaps with information about the thread that was terminated because
> of the exception.
> 
> Here is a monkey patch that simulates what I'm hoping to achieve with
> this bug:
> 
> ```ruby
> class << Thread
> �� alias old_new new
> 
> �� def new(*args, &block)
> ��������old_new(*args) do |*bargs|
> ������������begin
> ����������������block.call(*bargs)
> ������������rescue Exception => e
> ����������������raise if Thread.abort_on_exception ||
> Thread.current.abort_on_exception
> ����������������puts "Thread for block #{block.inspect} terminated with
> exception: #{e.message}"
> ����������������puts e.backtrace.map {|line| "����#{line}"}
> ������������end
> ��������end
> �� end
> end
> 
> Thread.new { 1 / 0 }.join
> puts "After thread"������
> ```
> 
> Output:
> 
> ```
> system ~/projects/jruby $ ruby thread_error.rb��
> Thread for block #<Proc:0x000000010d008a80@thread_error.rb:17>
> terminated with exception: divided by 0
> �� thread_error.rb:17:in `/'
> �� thread_error.rb:17
> �� thread_error.rb:7:in `call'
> �� thread_error.rb:7:in `new'
> �� thread_error.rb:5:in `initialize'
> �� thread_error.rb:5:in `old_new'
> �� thread_error.rb:5:in `new'
> �� thread_error.rb:17
> After thread
> ```
> 
> 
> 

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>