Bug #14074: TracePoint#new without a block should not raise ThreadError

• Status: Closed
• Assignee: marcandre (Marc-Andre Lafortune)
• Target version: 2.5
• ruby -v: trunk
• Backport: 2.3: UNKNOWN, 2.4: UNKNOWN

[atul (Atul Bhosale)]

While working on RubySpecs with Marc-Andre Lafortune, we discovered that TracePoint.new raises a ThreadError instead of ArgumentError.
For example :

TracePoint.new => # => ThreadError: must be called with a block

[atul (Atul Bhosale)]

While working on RubySpecs with Marc-Andre Lafortune, we discovered that TracePoint.new raises a ThreadError instead of ArgumentError.
For example :

TracePoint.new => # => ThreadError: must be called with a block

[marcandre (Marc-Andre Lafortune)]

• Assignee set to marcandre (Marc-Andre Lafortune)
• Target version set to 2.5

Is there an objection to change this to an ArgumentError?

I wouldn't be asking if the documentation wasn't mentioning it, but sadly it is.

I believe the reason it a ThreadError is raised is that:

1. the code in question was simply copy-pasted from thread.c or thread_sync.c:

$ grep "must be called with a block" *.c
thread.c:	rb_raise(rb_eThreadError, "must be called with a block");
thread_sync.c:	rb_raise(rb_eThreadError, "must be called with a block");
vm_trace.c:	rb_raise(rb_eThreadError, "must be called with a block");

2. When Zack documented the TracePoint API, he simply wrote what the behavior was, without questioning it. [#6895]

I don't believe there's actual cases in production of TracePoint.new being called without a black. Nevertheless, we might as well fix this.

So unless there's an objection, I will change the code to raise an ArgumentError and modify the documentation so it does not mention the class of error raised, like in the rest of the documentation.

FWIW, Thread.new and Mutex#synchronize raising ThreadError also seem wrong to be me.

[marcandre (Marc-Andre Lafortune)]

• Status changed from Open to Closed