[#103680] [Ruby master Bug#17843] Ruby on Rails error[BUG] Segmentation fault at 0x0000000000000110 ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-darwin15] (#42110) — nayaronfire@...

Issue #17843 has been reported by nayaronfire (kk nayar).

7 messages 2021/05/01

[#103686] [Ruby master Misc#17845] Windows Ruby - ucrt build? — Greg.mpls@...

Issue #17845 has been reported by MSP-Greg (Greg L).

22 messages 2021/05/01

[#103690] [Ruby master Bug#17846] Percent mode changes the output from ERB beyond what is documented — wolf@...

Issue #17846 has been reported by graywolf (Gray Wolf).

8 messages 2021/05/02

[#103724] [Ruby master Feature#17849] Fix Timeout.timeout so that it can be used in threaded Web servers — duerst@...

Issue #17849 has been reported by duerst (Martin Dst).

22 messages 2021/05/05

[#103756] [Ruby master Feature#17853] Add Thread#thread_id — komamitsu@...

Issue #17853 has been reported by komamitsu (Mitsunori Komatsu).

11 messages 2021/05/06

[#103801] [Ruby master Feature#17859] Start IRB when running just `ruby` — deivid.rodriguez@...

Issue #17859 has been reported by deivid (David Rodr刕uez).

18 messages 2021/05/12

[#103866] [Ruby master Bug#17866] Incompatible changes with Psych 4.0.0 — hsbt@...

Issue #17866 has been reported by hsbt (Hiroshi SHIBATA).

13 messages 2021/05/17

[#103892] [Ruby master Bug#17871] TestGCCompact#test_ast_compacts test failing again — jaruga@...

Issue #17871 has been reported by jaruga (Jun Aruga).

11 messages 2021/05/19

[#103912] [Ruby master Bug#17873] Update of default gems in Ruby 3.1 — hsbt@...

Issue #17873 has been reported by hsbt (Hiroshi SHIBATA).

38 messages 2021/05/20

[#103971] [Ruby master Bug#17880] [BUG] We are killing the stack canary set by `opt_setinlinecache` — jean.boussier@...

Issue #17880 has been reported by byroot (Jean Boussier).

8 messages 2021/05/22

[#103974] [Ruby master Feature#17881] Add a Module#const_added callback — jean.boussier@...

Issue #17881 has been reported by byroot (Jean Boussier).

29 messages 2021/05/22

[#104004] [Ruby master Feature#17883] Load bundler/setup earlier to make `bundle exec ruby -r` respect Gemfile — mame@...

Issue #17883 has been reported by mame (Yusuke Endoh).

21 messages 2021/05/24

[#104109] [Ruby master Feature#17930] Add column information into error backtrace — mame@...

Issue #17930 has been reported by mame (Yusuke Endoh).

34 messages 2021/05/31

[ruby-core:104064] [Ruby master Feature#15567] Allow ensure to match specific situations

From: merch-redmine@...
Date: 2021-05-27 13:38:22 UTC
List: ruby-core #104064
Issue #15567 has been updated by jeremyevans0 (Jeremy Evans).


ioquatix (Samuel Williams) wrote in #note-14:
> Here is working example:
> 
> ~~~ ruby
> def transaction
> 	failed = false
> 	
> 	begin
> 		puts "Begin Transaction"
> 		yield
> 	rescue Exception
> 		puts "Abort Transaction"
> 		failed = true
> 		raise
> 	ensure
> 		puts "Commit Transaction" unless failed
> 	end
> end
> 
> catch(:ball) do
> 	begin
> 		raise "Problem"
> 	rescue
> 		transaction do
> 			throw :ball
> 		end
> 	end
> end
> ~~~
> 
> This seems overly complex to me personally.

You can simplify this slightly using a local variable:

```ruby
def transaction
    failed = false

    begin
        puts "Begin Transaction"
        yield
    rescue Exception => exc
        puts "Abort Transaction"
        raise
    ensure
        puts "Commit Transaction" unless exc
    end
end

catch(:ball) do
    begin
        raise "Problem"
    rescue
        transaction do
            throw :ball
        end
    end
end
```

I think such code makes sense.  Exceptions abort the transaction, but should be reraised and not swallowed, so the `raise` doesn't feel out of place.

Looking at my earlier example:

```ruby
def doot
  ret = yield
  normal_exit = true
  ret
ensure                                                                                                                                                                                                              
  # Did the block return normally
  return "abnormal" if $! || !normal_exit
end
```

This is a case that wouldn't work correctly in the transaction scenario, where it is called inside an existing `rescue` block.  So you would currently have to use:

```ruby
def doot
  ret = yield
  normal_exit = true
  ret
rescue Exception => exc
  raise
ensure                                                                                                                                                                                                              
  # Did the block return normally
  return "abnormal" if exc || !normal_exit
end
```

About the only way I can think to make that easier would be for `ensure` to support `=>`:

```ruby
def doot
  ret = yield
  normal_exit = true
  ret
ensure => exc                                                                                                                                                                                                        
  # Did the block return normally
  return "abnormal" if exc || !normal_exit
end
```

In this case `exc` would be `nil` if the code before ensure did not raise an exception, and the exception instance if it did.

However, I think the cases where this actually matters (`ensure` without `rescue` but that cares about whether an exception has been raised) are so few that we shouldn't consider language modifications to support them.

----------------------------------------
Feature #15567: Allow ensure to match specific situations
https://bugs.ruby-lang.org/issues/15567#change-92238

* Author: ioquatix (Samuel Williams)
* Status: Rejected
* Priority: Normal
* Assignee: ioquatix (Samuel Williams)
----------------------------------------
There are some situations where `rescue Exception` or `ensure` are not sufficient to correctly, efficiently and easily handle abnormal flow control.

Take the following program for example:

```
def doot
	yield
ensure
	# Did the function run to completion?
	return "abnormal" if $!
end

puts doot{throw :foo}
puts doot{raise "Boom"}
puts doot{"Hello World"}

catch(:foo) do
	puts doot{throw :foo}
end
```

Using `rescue Exception` is not sufficient as it is not invoked by `throw`.

Using `ensure` is inefficient because it's triggered every time, even though exceptional case might never happen or happen very infrequently.

I propose some way to limit the scope of the ensure block:

```
def doot
	yield
ensure when raise, throw
	return "abnormal"
end
```

The scope should be one (or more) of `raise`, `throw`, `return`, `next`, `break`, `redo`, `retry` (everything in `enum ruby_tag_type` except all except for `RUBY_TAG_FATAL`).

Additionally, it might be nice to support the inverted pattern, i.e.

```
def doot
	yield
ensure when not return
	return "abnormal"
end
```

Inverted patterns allow user to specify the behaviour without having problems if future scopes are introduced.

`return` in this case matches both explicit and implicit.




-- 
https://bugs.ruby-lang.org/

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

In This Thread

Prev Next