In Ruby 2.4 when we pass a block to a method, which further passes to anothermethod, Ruby creates a new Proc object by the given block before passing thisproc to the another method.

This creates unnecessary objects even when the block parameter is not accessed.It also creates a chain of Proc objects when the block parameter is passedthrough various methods.

Proc creation is one a heavyweight operation because we need to store all localvariables (represented by Env objects in MRI internal) in the heap.

Ruby 2.5 introduced a lazy proc allocation. Ruby 2.5 will not create a Procobject when passing a block to another method. Instead, it will pass the blockinformation. If the block is accessed somewhere else, then it creates a Procobject by the given block.

This results in lesser memory allocation and faster execution.

Ruby 2.4

irb> require 'benchmark'  => trueirb> def greetirb>   yieldirb> end  => :greetirb>irb> def greet_with_welcome(&block)irb>   puts 'Welcome'irb>   greet(&block)irb> end  => :greet_with_welcomeirb>irb> Benchmark.measure { 1000.times { greet_with_welcome { 'BigBinary' } } }WelcomeWelcome.........  => #<Benchmark::Tms:0x007fe6ab929de0 @label="", @real=0.022295999999187188, @cstime=0.0, @cutime=0.0, @stime=0.01, @utime=0.0, @total=0.01>

Ruby 2.5

irb> require 'benchmark'  => trueirb> def greetirb>   yieldirb> end  => :greetirb>irb> def greet_with_welcome(&block)irb>   puts 'Welcome'irb>   greet(&block)irb> end  => :greet_with_welcomeirb>  irb> Benchmark.measure { 1000.times { greet_with_welcome { 'BigBinary' } } }WelcomeWelcome.........  => #<Benchmark::Tms:0x00007fa4400871b8 @label="", @real=0.004612999997334555, @cstime=0.0, @cutime=0.0, @stime=0.001524000000000001, @utime=0.0030690000000000023, @total=0.004593000000000003>

As we can see, there is considerable improvement in execution time when a blockparam is passed in Ruby 2.5.

Here is the relevant commitand discussion.

division_thread = Thread.new do  puts "Calculating 4/0 in division_thread"  puts "Result is: #{4/0}"  puts "Exiting from division_thread"endsleep 1puts "In the main thread"

Execution of it looks like this.

$ RBENV_VERSION=2.4.0 ruby thread_example_1.rbCalculating 4/0 in division_threadIn the main thread

Note that the last two lines from the block were not printed. Also notice thatafter failing in the thread the program continued to run in main thread. That'swhy we got the message "In the main thread".

This is because the default behavior of Ruby is to silently ignore exceptions inthreads and then to continue to execute in the main thread.

Enabling abort_on_exception to stop on failure

If we want an exception in a thread to stop further processing both in thethread and in the main thread then we can enable Thread[.#]abort_on_exceptionon that thread to achieve that.

Notice that in the below code we are using Thread.current.

division_thread = Thread.new do  Thread.current.abort_on_exception = true  puts "Calculating 4/0 in division_thread"  puts "Result is: #{4/0}"  puts "Exiting from division_thread"endsleep 1puts "In the main thread"

$ RBENV_VERSION=2.4.0 ruby thread_example_2.rbCalculating 4/0 in division_threadthread_example_2.rb:5:in `/': divided by 0 (ZeroDivisionError)  from thread_example_2.rb:5:in `block in <main>'

As we can see once an exception was encountered in the thread then processingstopped on both in the thread and in the main thread.

Note that Thread.current.abort_on_exception = true activates this behavioronly for the current thread.

If we want this behavior globally for all the threads then we need to useThread.abort_on_exception = true.

Running program with debug flag to stop on failure

Let's run the original code with --debug option.

$ RBENV_VERSION=2.4.0 ruby --debug thread_example_1.rbthread_example_1.rb:1: warning: assigned but unused variable - division_threadCalculating 4/0 in division_threadException `ZeroDivisionError' at thread_example_1.rb:3 - divided by 0Exception `ZeroDivisionError' at thread_example_1.rb:7 - divided by 0thread_example_1.rb:3:in `/': divided by 0 (ZeroDivisionError)  from thread_example_1.rb:3:in `block in <main>'

In this case the exception is printed in detail and the code in main thread wasnot executed.

Usually when we execute a program with --debug option then the behavior of theprogram does not change. We expect the program to print more stuff but we do notexpect behavior to change. However in this case the --debug option changes thebehavior of the program.

Running program with join on thread to stop on failure

If a thread raises an exception and abort_on_exception and $DEBUG flags arenot set then that exception will be processed at the time of joining of thethread.

division_thread = Thread.new do  puts "Calculating 4/0 in division_thread"  puts "Result is: #{4/0}"  puts "Exiting from division_thread"enddivision_thread.joinputs "In the main thread"

$ RBENV_VERSION=2.4.0 ruby thread_example_3.rbCalculating 4/0 in division_threadthread_example_3.rb:3:in `/': divided by 0 (ZeroDivisionError)  from thread_example_3.rb:3:in `block in <main>'

Both Thread#join and Thread#value will stop processing in the thread and inthe main thread once an exception is encountered.

Introduction of report_on_exception in Ruby 2.4

Almost 6 years ago, Charles Nutter (headius) hadproposed that the exceptions raised in threads should be automatically loggedand reported, by default. To make his point, he explained issues similar to whatwe discussed above about the Ruby's behavior of silently ignoring exceptions inthreads. Here is the relevantdiscussion on his proposal.

Following are some of the notable points discussed.

• Enabling Thread[.#]abort_on_exception, by default, is not always a goodidea.
• There should be a flag which, if enabled, would print the thread-killingexception info.
• In many cases, people spawn one-off threads which are not hard-referencedusing Thread#join or Thread#value. Such threads gets garbage collected.Should it report the thread-killing exception at the time of garbagecollection if such a flag is enabled?
• Should it warn usingWarning#warnor redirect to STDERR device while reporting?

Charles Nutter suggested that a configurable global flagThread.report_on_exception and instance-level flagThread#report_on_exception should be implemented having its default value astrue. When set to true, it should report print exception information.

Matz and other core members approved that Thread[.#]report_on_exception can beimplemented having its default value set to false.

Charles Nutter, Benoit Daloze and other people demanded that it should be trueby default so that programmers can be aware of the silently disappearing threadsbecause of exceptions.

Shyouhei Urabe advised thatdue to some technical challenges, the default value should be set to false soas this feature could land in Ruby. Once this feature is in then the defaultvalue can be changed in a later release.

Nobuyoshi Nakada (nobu) pushed animplementationfor Thread[.#]report_on_exception with a default value set to false. It wasreleased in Ruby 2.4.0.

Let's try enabling report_on_exception globally usingThread.report_on_exception.

Thread.report_on_exception = truedivision_thread = Thread.new do  puts "Calculating 4/0 in division_thread"  puts "Result is: #{4/0}"  puts "Exiting from division_thread"endaddition_thread = Thread.new do  puts "Calculating nil+4 in addition_thread"  puts "Result is: #{nil+4}"  puts "Exiting from addition_thread"endsleep 1puts "In the main thread"

$ RBENV_VERSION=2.4.0 ruby thread_example_4.rbCalculating 4/0 in division_thread#<Thread:0x007fb10f018200@thread_example_4.rb:3 run> terminated with exception:thread_example_4.rb:5:in `/': divided by 0 (ZeroDivisionError)  from thread_example_4.rb:5:in `block in <main>'Calculating nil+4 in addition_thread#<Thread:0x007fb10f01aca8@thread_example_4.rb:9 run> terminated with exception:thread_example_4.rb:11:in `block in <main>': undefined method `+' for nil:NilClass (NoMethodError)In the main thread

It now reports the exceptions in all threads. It prints that theThread:0x007fb10f018200 wasterminated with exception: divided by 0 (ZeroDivisionError). Similarly,another thread Thread:0x007fb10f01aca8 wasterminated with exception: undefined method '+' for nil:NilClass (NoMethodError).

Instead of enabling it globally for all threads, we can enable it for aparticular thread using instance-level Thread#report_on_exception.

division_thread = Thread.new do  puts "Calculating 4/0 in division_thread"  puts "Result is: #{4/0}"  puts "Exiting from division_thread"endaddition_thread = Thread.new do  Thread.current.report_on_exception = true  puts "Calculating nil+4 in addition_thread"  puts "Result is: #{nil+4}"  puts "Exiting from addition_thread"endsleep 1puts "In the main thread"

In the above case we have enabled report_on_exception flag just foraddition_thread.

Let's execute it.

$ RBENV_VERSION=2.4.0 ruby thread_example_5.rbCalculating 4/0 in division_threadCalculating nil+4 in addition_thread#<Thread:0x007f8e6b007f70@thread_example_5.rb:7 run> terminated with exception:thread_example_5.rb:11:in `block in <main>': undefined method `+' for nil:NilClass (NoMethodError)In the main thread

Notice how it didn't report the exception which killed thread division_thread.As expected, it reported the exception that killed thread addition_thread.

With the above changes ruby reports the exception as soon as it encounters.However if these threads are joined then they will still raise exception.

division_thread = Thread.new do  Thread.current.report_on_exception = true  puts "Calculating 4/0 in division_thread"  puts "Result is: #{4/0}"  puts "Exiting from division_thread"endbegin  division_thread.joinrescue => exception  puts "Explicitly caught - #{exception.class}: #{exception.message}"endputs "In the main thread"

$ RBENV_VERSION=2.4.0 ruby thread_example_6.rbCalculating 4/0 in division_thread#<Thread:0x007f969d00d828@thread_example_6.rb:1 run> terminated with exception:thread_example_6.rb:5:in `/': divided by 0 (ZeroDivisionError)  from thread_example_6.rb:5:in `block in <main>'Explicitly caught - ZeroDivisionError: divided by 0In the main thread

See how we were still be able to handle the exception raised indivision_thread above after joining it despite it reported it before due toThread#report_on_exception flag.

report_on_exception defaults to true in Ruby 2.5

Benoit Daloze (eregon) strongly advocated that boththe Thread.report_on_exception and Thread#report_on_exception should havedefault value as true. Here is therelevant feature request.

After approval from Matz,Benoit Daloze pushed theimplementationby fixing the failing tests and silencing the unnecessary verbose warnings.

It was released as part of Ruby 2.5.

Now in ruby 2.5 we can simply write like this.

division_thread = Thread.new do  puts "Calculating 4/0 in division_thread"  puts "Result is: #{4/0}"  puts "Exiting from division_thread"endaddition_thread = Thread.new do  puts "Calculating nil+4 in addition_thread"  puts "Result is: #{nil+4}"  puts "Exiting from addition_thread"endsleep 1puts "In the main thread"

Let's execute it with Ruby 2.5.

$ RBENV_VERSION=2.5.0 ruby thread_example_7.rbCalculating 4/0 in division_thread#<Thread:0x00007f827689a238@thread_example_7.rb:1 run> terminated with exception (report_on_exception is true):Traceback (most recent call last):  1: from thread_example_7.rb:3:in `block in <main>'thread_example_7.rb:3:in `/': divided by 0 (ZeroDivisionError)Calculating nil+4 in addition_thread#<Thread:0x00007f8276899b58@thread_example_7.rb:7 run> terminated with exception (report_on_exception is true):Traceback (most recent call last):thread_example_7.rb:9:in `block in <main>': undefined method `+' for nil:NilClass (NoMethodError)In the main thread

We can disable the thread exception reporting globally usingThread.report_on_exception = false or for a particular thread usingThread.current.report_on_exception = false.

Future Possibilities

In addition to this feature, Charles Nutter alsosuggested that it will be goodif there exists a callback handler which can accept a block to be executed whena thread dies due to an exception. The callback handler can be at global levelor it can be for a specific thread.

Thread.on_exception do  # some stuffend

In the absence of such handler libraries need to resort to custom code to handleexceptions.Here is howSidekiq handles exceptions raised in threads.

Important thing to note is that report_on_exception does not change behaviorof the code. It does more reporting when a thread dies and when it comes tothread dies more reporting is a good thing.

Before Ruby 2.5

Before Ruby 2.5, we could measure just the line coverage using Coverage.

Line coverage tells us whether a line is executed or not. If executed, then howmany times that line was executed.

We have a file called score.rb.

score = 33if score >= 40  p :PASSEDelse  p :FAILEDend

Now create another file score_coverage.rb.

require "coverage"Coverage.startload "score.rb"p Coverage.result

We used Coverage#start method to measure the coverage of score.rb file.Coverage#result returns the coverage result.

Let's run it with Ruby 2.4.

$ RBENV_VERSION=2.4.0 ruby score_coverage.rb:FAILED{ "score.rb"=> [1, nil, 1, 0, nil, 1, nil] }

Let's look at the output. Each value in the array [1, nil, 1, 0, nil, 1, nil]denotes the count of line executions by the interpreter for each line inscore.rb file.

This array is also called the "line coverage" of score.rb file.

A nil value in line coverage array means coverage is disabled for thatparticular line number or it is not a relevant line. Lines like else, endand blank lines have line coverage disabled.

Here's how we can read above line coverage result.

• Line number 1 (i.e. 0th index in the above result array) was executed once.
• Coverage was disabled for line number 2 (i.e. index 1) as it is blank.
• Line number 3 (i.e. index 2) was executed once.
• Line number 4 did not execute.
• Coverage was disabled for line number 5 as it contains only else clause.
• Line number 6 was executed once.
• Coverage was disabled for line number 7 as it contains just end keyword.

After Ruby 2.5

There was a pull request opened in 2014to add method coverage and decision coverage metrics in Ruby. It wasrejected byYusuke Endoh as he saw some issues with it andmentioned that he was also working on a similar implementation.

In Ruby 2.5, Yusuke Endohadded branch coverage and method coverage featureto the Coverage library.

Let's see what's changed in Coverage library in Ruby 2.5.

Line Coverage

If we execute above example using Ruby 2.5, we will see no change in the result.

$ RBENV_VERSION=2.5.0 ruby score_coverage.rb:FAILED{ "score.rb" => [1, nil, 1, 0, nil, 1, nil] }

This behavior is maintained to ensure that the Coverage#start API stays 100%backward compatible.

If we explicitly enable lines option on Coverage#start method in the abovescore_coverage.rb file, the coverage result will be different now.

require "coverage"Coverage.start(lines: true)load "score.rb"p Coverage.result

$ RBENV_VERSION=2.5.0 ruby score_coverage.rb:FAILED{ "score.rb" => {    :lines => [1, nil, 1, 0, nil, 1, nil]  }}

We can see that the coverage result is now a hash which reads that thescore.rb file has lines coverage as [1, nil, 1, 0, nil, 1, nil].

Branch Coverage

Branch coverage helps us identify which branches are executed and which ones arenot executed.

Let's see how to get branch coverage.

We will update the score_coverage.rb by enabling branches option.

require "coverage"Coverage.start(branches: true)load "score.rb"p Coverage.result

$ RBENV_VERSION=2.5.0 ruby score_coverage.rb:FAILED{ "score.rb" =>  { :branches => {      [:if, 0, 3, 0, 7, 3] => {        [:then, 1, 4, 2, 4, 15] => 0,        [:else, 2, 6, 2, 6, 15] => 1      }    }  }}

Here is how to read the data in array.

[  BRANCH_TYPE,  UNIQUE_ID,  START_LINE_NUMBER,  START_COLUMN_NUMBER,  END_LINE_NUMBER,  END_COLUMN_NUMBER]

Please note that column numbers start from 0 and line numbers start from 1.

Let's try to read above printed branch coverage result.

[:if, 0, 3, 0, 7, 3] reads that if statement starts at line 3 & column 0 andends at line 7 & column 3.

[:then, 1, 4, 2, 4, 15] reads that then clause starts at line 4 & column 2and ends at line 4 & column 15.

Similarly, [:else, 2, 6, 2, 6, 15] reads that else clause starts at line 6 &column 2 and ends at line 6 & column 15.

Most importantly as per the branch coverage format, we can see that the branchfrom if to then was never executed since COUNTER is 0. The anotherbranch from if to else was executed once since COUNTER is 1.

Method Coverage

Measuring method coverage helps us identify which methods were invoked and whichwere not.

We have a file grade_calculator.rb.

students_scores = { "Sam" => [53, 91, 72],                    "Anna" => [91, 97, 95],                    "Bob" => [33, 69, 63] }def average(scores)  scores.reduce(&:+)/scores.sizeenddef grade(average_score)  case average_score  when 90.0..100.0 then :A  when 80.0..90.0 then :B  when 70.0..80.0 then :C  when 60.0..70.0 then :D  else :F  endenddef greet  puts "Congratulations!"enddef warn  puts "Try hard next time!"endstudents_scores.each do |student_name, scores|  achieved_grade = grade(average(scores))  puts "#{student_name}, you've got '#{achieved_grade}' grade."  if achieved_grade == :A    greet  elsif achieved_grade == :F    warn  end  putsend

To measure method coverage of above file, let's creategrade_calculator_coverage.rb by enabling methods option on Coverage#startmethod.

require "coverage"Coverage.start(methods: true)load "grade_calculator.rb"p Coverage.result

Let's run it using Ruby 2.5.

$ RBENV_VERSION=2.5.0 ruby grade_calculator_coverage.rbSam, you've got 'C' grade.Anna, you've got 'A' grade.Congratulations!Bob, you've got 'F' grade.Try hard next time!{ "grade_calculator.rb" => {    :methods => {      [Object, :warn, 23, 0, 25, 3] => 1,      [Object, :greet, 19, 0, 21, 3] => 1,      [Object, :grade, 9, 0, 17, 3] => 3,      [Object, :average, 5, 0, 7, 3] => 3    }  }}

The format of method coverage result is defined as shown below.

[ CLASS_NAME,  METHOD_NAME,  START_LINE_NUMBER,  START_COLUMN_NUMBER,  END_LINE_NUMBER,  END_COLUMN_NUMBER ]

Therefore, [Object, :grade, 9, 0, 17, 3] => 3 reads that the Object#grademethod which starts from line 9 & column 0 to line 17 & column 3 was invoked 3times.

Conclusion

We can measure all coverages at once also.

Coverage.start(lines: true, branches: true, methods: true)

What's the use of these different types of coverages anyway?

Well, one use case is to integrate this in a test suite and to determine whichlines, branches and methods are executed and which ones are not executed by thetest. Further, we can sum up these and evaluate total coverage of a test suite.

Author of this feature, Yusuke Endoh has releasedcoverage-helpers gem which allowsfurther advanced manipulation and processing of coverage results obtained usingCoverage#result.

class AverageService  attr_reader :numbers, :coerced_numbers  def initialize(numbers)    @numbers = numbers    @coerced_numbers = coerce_numbers  end  def average    sum / count  end  private  def coerce_numbers    numbers.map do |number|      begin        Float(number)      rescue Exception => exception        puts "#{exception.message} (#{exception.class})\n\t#{exception.backtrace.join("\n\t")}"        puts "Coercing '#{number}' as 0.0\n\n"        0.0      end    end  end  def sum    coerced_numbers.map(&:to_f).sum  end  def count    coerced_numbers.size.to_f  endendaverage = AverageService.new(ARGV).averageputs "Average is: #{average}"

$ RBENV_VERSION=2.4.0 ruby average_service.rb 5 4f 7 1s0invalid value for Float(): "4f" (ArgumentError)average_service.rb:18:in `Float'average_service.rb:18:in `block in coerce_numbers'average_service.rb:16:in `map'average_service.rb:16:in `coerce_numbers'average_service.rb:6:in `initialize'average_service.rb:37:in `new'average_service.rb:37:in `<main>'Coercing '4f' as 0.0invalid value for Float(): "1s0" (ArgumentError)average_service.rb:18:in `Float'average_service.rb:18:in `block in coerce_numbers'average_service.rb:16:in `map'average_service.rb:16:in `coerce_numbers'average_service.rb:6:in `initialize'average_service.rb:37:in `new'average_service.rb:37:in `<main>'Coercing '1s0' as 0.0Average of [5.0, 0.0, 7.0, 0.0] is: 3.0

It was proposed that there should bea simple method to print the caught exception using the same format that rubyuses while printing an uncaught exception.

Some of the proposed method names were display, formatted, to_formatted_s,long_message, and full_message.

Matz approved theException#full_message method name.

In Ruby 2.5, we can re-write above example as follows.

class AverageService  attr_reader :numbers, :coerced_numbers  def initialize(numbers)    @numbers = numbers    @coerced_numbers = coerce_numbers  end  def average    sum / count  end  private  def coerce_numbers    numbers.map do |number|      begin        Float(number)      rescue Exception => exception        puts exception.full_message        puts "Coercing '#{number}' as 0.0\n\n"        0.0      end    end  end  def sum    coerced_numbers.map(&:to_f).sum  end  def count    coerced_numbers.size.to_f  endendaverage = AverageService.new(ARGV).averageputs "Average is: #{average}"

$ RBENV_VERSION=2.5.0 ruby average_service.rb 5 4f 7 1s0Traceback (most recent call last):6: from average_service.rb:37:in `<main>'5: from average_service.rb:37:in `new'4: from average_service.rb:6:in `initialize'3: from average_service.rb:16:in `coerce_numbers'2: from average_service.rb:16:in `map'1: from average_service.rb:18:in `block in coerce_numbers'average_service.rb:18:in `Float': invalid value for Float(): "4f" (ArgumentError)Coercing '4f' as 0.0Traceback (most recent call last):6: from average_service.rb:37:in `<main>'5: from average_service.rb:37:in `new'4: from average_service.rb:6:in `initialize'3: from average_service.rb:16:in `coerce_numbers'2: from average_service.rb:16:in `map'1: from average_service.rb:18:in `block in coerce_numbers'average_service.rb:18:in `Float': invalid value for Float(): "1s0" (ArgumentError)Coercing '1s0' as 0.0Average of [5.0, 0.0, 7.0, 0.0] is: 3.0

Note that, Ruby 2.5 prints exception backtrace in reverse order if STDERR isunchanged and is a TTY as discussedin our previous blog post.

Before Ruby 2.5

Before Ruby 2.5, the printed backtrace contained the exception class and theerror message at the top. Next line contained where in the program the exceptionwas raised. Next we got more lines which contained cascaded method calls.

Consider a simple Ruby program.

class DivisionService  attr_reader :a, :b  def initialize(a, b)    @a, @b = a.to_i, b.to_i  end  def divide    puts a / b  endendDivisionService.new(ARGV[0], ARGV[1]).divide

Let's execute it using Ruby 2.4.

$ RBENV_VERSION=2.4.0 ruby division_service.rb 5 0division_service.rb:9:in `/': divided by 0 (ZeroDivisionError)from division_service.rb:9:in `divide'from division_service.rb:13:in `<main>'

In the printed backtrace above, the first line shows the location, error messageand the exception class name; whereas the subsequent lines shows the callermethod names and their locations. Each line in the backtrace above is oftenconsidered as a stack frame placed on the call stack.

Most of the times, a backtrace has so many lines that it makes it very difficultto fit the whole backtrace in the visible viewport of the terminal.

Since the backtrace is printed in top to bottom order the meaningful informationlike error message, exception class and the exact location where the exceptionwas raised is displayed at top of the backtrace. It means developers often needto scroll to the top in the terminal window to find out what went wrong.

After Ruby 2.5

Over 4 years ago an issue was createdto make printing of backtrace in reverse order configurable.

After much discussion Nobuyoshi Nakada made the commit to print backtrace anderror messagein reverse orderonly when the error output device (STDERR) is a TTY (i.e. a terminal). Messagewill not be printed in reverse order if the original STDERR is attached tosomething like a File object.

Look at the code herewhere the check happens if STDERR is a TTY and is unchanged.

Let's execute the same program using Ruby 2.5.

$ RBENV_VERSION=2.5.0 ruby division_service.rb 5 0Traceback (most recent call last):2: from division_service.rb:13:in `<main>'1: from division_service.rb:9:in `divide'division_service.rb:9:in `/': divided by 0 (ZeroDivisionError)$

We can notice two new changes in the above backtrace.

1. The error message and exception class is printed last (i.e. at the bottom).
2. The stack alsoadds frame numberwhen printing in reverse order.

This feature makes the debugging convenient when the backtrace size is a quitebig and cannot fit in the terminal window. We can easily see the error messagewithout scrolling up now.

Note that, the Exception#backtrace attribute still holds an array of stackframes like before in the top to bottom order.

So if we rescue the caught exception and print the backtrace manually

class DivisionService  attr_reader :a, :b  def initialize(a, b)    @a, @b = a.to_i, b.to_i  end  def divide    puts a / b  endendbegin  DivisionService.new(ARGV[0], ARGV[1]).dividerescue Exception => e  puts "#{e.class}: #{e.message}"  puts e.backtrace.join("\n")end

we will get the old behavior.

$ RBENV_VERSION=2.5.0 ruby division_service.rb 5 0ZeroDivisionError: divided by 0division_service.rb:9:in `/'division_service.rb:9:in `divide'division_service.rb:16:in `<main>'$

Also, note that if we assign STDERR with a File object, thus making it anon-TTY

puts "STDERR is a TTY? [before]: #{$stderr.tty?}"$stderr = File.new("stderr.log", "w")$stderr.sync = trueputs "STDERR is a TTY? [after]: #{$stderr.tty?}"class DivisionService  attr_reader :a, :b  def initialize(a, b)    @a, @b = a.to_i, b.to_i  end  def divide    puts a / b  endendDivisionService.new(ARGV[0], ARGV[1]).divide

we can get the old behavior but the backtrace would be written to the specifiedfile and not to STDERR.

$ RBENV_VERSION=2.5.0 ruby division_service.rb 5 0STDERR is a TTY? [before]: trueSTDERR is a TTY? [after]: false$ cat stderr.logdivision_service.rb:14:in `/': divided by 0 (ZeroDivisionError)from division_service.rb:14:in `divide'from division_service.rb:18:in `<main>'$

This feature has been tagged asexperimental feature.What it means is that Ruby team isgathering feedbackon this feature.

Let's say we have a hash{ id: 1, name: 'Ruby 2.5', description: 'BigBinary Blog' } and we want toselect key value pairs having the keys name and description.

We can use theHash#select method.

irb> blog = { id: 1, name: 'Ruby 2.5', description: 'BigBinary Blog' }  => {:id=>1, :name=>"Ruby 2.5", :description=>"BigBinary Blog"}irb> blog.select { |key, value| [:name, :description].include?(key) }  => {:name=>"Ruby 2.5", :description=>"BigBinary Blog"}

Matzbara Masanao proposed a simplemethod to take care of this problem.

Some of the names proposed were choice and pick.

Matz suggested the name slice since thismethod is ActiveSupport compatible.

Ruby 2.5.0

irb> blog = { id: 1, name: 'Ruby 2.5', description: 'BigBinary Blog' }  => {:id=>1, :name=>"Ruby 2.5", :description=>"BigBinary Blog"}irb> blog.slice(:name, :description)  => {:name=>"Ruby 2.5", :description=>"BigBinary Blog"}

So, now we can use a simple method slice to select key value pairs from a hashwith specified keys.

Here is the relevant commitand discussion.

Customer = Struct.new(:name, :email)Customer.new("John", "john@example.com")

This approach works when the arguments list is short. When arguments listincreases then it gets harder to track which position maps to which value.

Here if we pass keyword argument then we won't get any error. But the values arenot what we wanted.

Customer.new(name: "John", email: "john@example.com")=> #<struct Customer name={:name=>"John", :email=>"john@example.com"}, email=nil>

Ruby 2.5 introducedcreating structs using keyword arguments.Relevant pull request is here.

However this introduces a problem. How do we indicate to Struct if we want topass arguments using position or keywords.

Takashi Kokubunsuggestedto use keyword_argument as an identifier.

Customer = Struct.new(:name, :email, keyword_argument: true)Customer.create(name: "John", email: "john@example.com")

Matzsuggestedto change the name to keyword_init.

So in Ruby 2.5 we can create structs using keywords as long as we are passingkeyword_init.

Customer = Struct.new(:name, :email, keyword_init: true)Customer.new(name: "John", email: "john@example.com")=> #<struct Customer name="John", email="john@example.com">

In Ruby 2.5, a similar methodHash#transform_keys is added fortransforming keys of the hash.

>> h = { name: "John", email: "john@example.com" }=> {:name=>"John", :email=>"john@example.com"}>> h.transform_keys { |k| k.to_s }=> {"name"=>"John", "email"=>"john@example.com"}

The bang sibling of this method, Hash#transform_keys! is also added whichchanges the hash in place.

These two methods are already present inActive Support from Railsand are natively supported in Ruby now.

Rails master is already supportingusing the native methods ifsupported by the Ruby version.

Ruby has sequence predicates such as all?, none?, one? and any? whichtake a block and evaluate that by passing every element of the sequence to it.

if queries.any? { |sql| /LEFT OUTER JOIN/i =~ sql }logger.log "Left outer join detected"end

Ruby 2.5 allows using a shorthand for this bypassing a pattern argument.Internally case equality operator(===) is used against every element of thesequence and the pattern argument.

if queries.any?(/LEFT OUTER JOIN/i)logger.log "Left outer join detected"end# Translates to:queries.any? { |sql| /LEFT OUTER JOIN/i === sql }

This allows us to write concise and shorthand expressions where block is onlyused for comparisons. This feature is applicable to all?, none?, one? andany? methods.

Similarities with Enumerable#grep

This feature is based on how Enumerable#grep works. grep returns an array ofevery element in the sequence for which the case equality operator(===)returns true by applying the pattern. In this case, the all? and friendsreturn true or false.

There is a proposal to add it forselect and reject as well.

Ruby allows pretty printing of objects usingpp method.

Before Ruby 2.5, we had to require PP explicitly before using it. Even theofficial documentation states that "All examples assume you have loaded the PPclass with require 'pp'".

>> months = %w(January February March)=> ["January", "February", "March"]>> pp monthsNoMethodError: undefined method `pp' for main:ObjectDid you mean?  pfrom (irb):5from /Users/prathamesh/.rbenv/versions/2.4.1/bin/irb:11:>> require 'pp'=> true>> pp months["January", "February", "March"]=> ["January", "February", "March"]

In Ruby 2.5, we don't need to require pp. Itgets required by default. We can useit directly.

>> months = %w(January February March)=> ["January", "February", "March"]>> pp months["January", "February", "March"]=> ["January", "February", "March"]

This feature was added after Ruby 2.5.0 preview 1 was released, so it's notpresent in the preview. It's present inRuby trunk.

The names of these methods are not very intuitive. Active Support from Railsalready has aliases forthe unshift and push methods, namely prepend and append.

In Ruby 2.5, these methodsare added in the Ruby language itself.

>> a = ["hello"]=> ["hello"]>> a.append "world"=> ["hello", "world"]>> a.prepend "Hey"=> ["Hey", "hello", "world"]>>

They are implemented as aliases to the original unshift and push methods sothere is no change in the behavior.

irb> "Hello".yield_self { |str| str + " World" }  => "Hello World"

How is it different from try in Rails ?

Without a method argument trybehaves similar to yield_self. It would yield to the given block unless thereceiver is nil and returns the output of the last statement in the block.

irb> "Hello".try { |str| str + " World" }  => "Hello World"

Couple of differences to note are, try is not part of Ruby but Rails. Alsotry's main purpose is protection against nil hence it doesn't execute theblock if receiver is nil.

irb> nil.yield_self { |obj| "Hello World" }  => "Hello World"irb> nil.try { |obj| "Hello World" }  => nil

What about tap?

tap also is similar to yield_self. It's part of Ruby itself. The onlydifference is the value that is returned. tap returns the receiver itselfwhile yield_self returns the output of the block.

irb> "Hello".yield_self { |str| str + " World" }  => "Hello World"irb> "Hello".tap { |str| str + " World" }  => "Hello"

Overall, yield_self improves readability of the code by promoting chainingover nested function calls. Here is an example of both the styles.

irb> add_greeting = -> (str) { "HELLO " + str }irb> to_upper = -> (str) { str.upcase }# with new `yield_self`irb> "world".yield_self(&to_upper)            .yield_self(&add_greeting)  => "HELLO WORLD"# nested function callsirb> add_greeting.call(to_upper.call("world"))  => "HELLO WORLD"

yield_self is part of Kernel and hence it's available to all the objects.

Let's say that we have a string Projects::CategoriesController and we want toremove Controller. We can usechomp method.

irb> "Projects::CategoriesController".chomp("Controller")=> "Projects::Categories"

However if we want to remove Projects:: from the string then there is nocorresponding method of chomp. We need to resort tosub.

irb> "Projects::CategoriesController".sub(/Projects::/, '')=> "CategoriesController"

Naotoshi Seo did not like using regularexpression for such a simple task. He proposed that Ruby should have a methodfor taking care of such tasks.

Some of the names proposed were remove_prefix, deprefix, lchomp,remove_prefix and head_chomp.

Matz suggested the name delete_prefix andthis method was born.

Ruby 2.5.0-preview1

irb> "Projects::CategoriesController".delete_prefix("Projects::")=> "CategoriesController"

Now in order to delete prefix we can use delete_prefix and to delete suffix wecould use chomp. This did not feel right. So for symmetry delete_suffix wasadded.

irb> "Projects::CategoriesController".delete_suffix("Controller")=> "Projects::Categories"

Read up on this discussion to learnmore about how elixir, go, python, and PHP deal with similar requirements.

> Dir.entries("/Users/john/Desktop/test")> => [".", "..", ".config", "program.rb", "group.txt"]>

We also have methodDir.foreach whichiterates and yields each value from the output of ls -a command to the block.

> Dir.foreach("/Users/john/Desktop/test") { |child| puts child }> .> ..> .config> program.rb> group.txt> test2>

We can see that the output includes the directives for current directory andparent directory which are "." and "..".

When we want to have access only to the children files and directories, we donot need the [".", ".."] subarray.

This is a very common use case and we'll probably have to do something likeDir.entries(path) - [".", ".."] to achieve the desired output.

To overcome such issues,Ruby 2.5 introduced Dir.children. Itreturns the output of ls -a command without the directives for current andparent directories.

> Dir.children("/Users/mohitnatoo/Desktop/test")> => [".config", "program.rb", "group.txt"]>

Additionally, we can use Dir.each_child method to avoid yielding current andparent directory directives while iterating,

> Dir.each_child("/Users/mohitnatoo/Desktop/test") { |child| puts child }> .config> program.rb> group.txt> test2>

As noted in the discussion the nameswere chosen to match with existing methodsPathname#childrenandPathname#each_child.

These additions seem like simple features. Well the issue was posted more thantwo years ago.

irb> array_from_user = [4, 2, 0, 1]  => [4, 2, 0, 1]irb> array_from_user.each do |number|irb>   p 10 / numberirb> rescue ZeroDivisionError => exceptionirb>   p exceptionirb>   nextirb> endSyntaxError: (irb):4: syntax error, unexpected keyword_rescue,expecting keyword_endrescue ZeroDivisionError => exception      ^

Ruby 2.4 throws an error when we try to use rescue/else/ensure inside do/endblocks.

Ruby 2.5.0-preview1

irb> array_from_user = [4, 2, 0, 1]  => [4, 2, 0, 1]irb> array_from_user.each do |number|irb>   p 10 / numberirb> rescue ZeroDivisionError => exceptionirb>   p exceptionirb>   nextirb> end25#<ZeroDivisionError: divided by 0>10 => [4, 2, 0, 1]

Ruby 2.5 supports rescue/else/ensure inside do/end blocks.

Here is relevant commit anddiscussion.

irb> class Projectirb> end=> nilirb> class Categoryirb> end=> nilirb> Project::Category(irb):5: warning: toplevel constant Category referenced by Project::Category => Category

Ruby 2.4 returns the top level constant with a warning if it is unable to find aconstant in the specified scope.

This does not work well in cases where we need constants to be defined with samename at top level and also in the same scope.

Ruby 2.5.0-preview1

irb> class Projectirb> end=> nilirb> class Categoryirb> end=> nilirb> Project::CategoryNameError: uninitialized constant Project::CategoryDid you mean?  Categoryfrom (irb):5

Ruby 2.5 throws an error if it is unable to find a constant in the specifiedscope.

Here is the relevant commitand discussion.