ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: "ioquatix (Samuel Williams)" <noreply@ruby-lang.org>
To: ruby-core@ruby-lang.org
Subject: [ruby-core:105019] [Ruby master Feature#18083] Capture error in ensure block.
Date: Fri, 20 Aug 2021 01:09:35 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-93421.20210820010935.3344@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-18083.20210818030342.3344@ruby-lang.org

Issue #18083 has been updated by ioquatix (Samuel Williams).


> the exception that happens inside is not a proof the resource is at fault, it could be anything, including a NoMemoryError or a SystemStackError for instance (which e.g. could be due to a bug in the block, not related to the resource at all).

Yes, it's a fair assessment. But the key point is there is a different from normal exit (which can include `throw`) and exceptional exit (exception was raised during user code). The reality is, as shown by the examples, lots of code does need to make this differentiation.

> You literally want to test "any Ruby exception" or "any other exit from this block", and then rescue Exception just makes sense.

Actually, I'm less concerned about the "any Ruby exception" and more concerned with splitting execution between "normal code flow" and "exceptional code flow", and even that is just as an example. Clearly, lots of people **are** using `$!` in an unsafe way, and that's the key point I want to fix. My initial proposal is one way to fix it, by introducing explicit `ensure => error`. However, I agree with Matz, that it can be considered kind of ugly. But if that's true, why don't we get rid of `$!`, surely every case for `$!` can be better handled by explicit `rescue`? If not, why is `$!` necessary? If we can answer that question, then I think we will know what path to take.

Personally, I'd vote for the path to get rid of `$!` because I do agree with Matz that its fundamentally pretty ugly both sematically, as well as practically. I looked at a lot of code that uses `$!` and it's often used as a poor replacement for the implicit exception `cause` argument, or for implicit passing error information between code where it should really be explicit.


----------------------------------------
Feature #18083: Capture error in ensure block.
https://bugs.ruby-lang.org/issues/18083#change-93421

* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
----------------------------------------
As discussed in https://bugs.ruby-lang.org/issues/15567 there are some tricky edge cases.

As a general model, something like the following would be incredibly useful:

``` ruby
begin
 ...
ensure => error
  pp "error occurred" if error
end
```

Currently you can get similar behaviour like this:

``` ruby
begin
  ...
rescue Exception => error
  raise
ensure
  pp "error occurred" if error
end
```

The limitation of this approach is it only works if you don't need any other `rescue` clause. Otherwise, it may not work as expected or require extra care. Also, Rubocop will complain about it.

Using `$!` can be buggy if you call some method from `rescue` or `ensure` clause, since it would be set already. It was discussed extensively in https://bugs.ruby-lang.org/issues/15567 if you want more details.



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

  parent reply	other threads:[~2021-08-20  1:09 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18  3:03 [ruby-core:104960] [Ruby master Feature#18083] Capture error in ensure block ioquatix (Samuel Williams)
2021-08-18  3:09 ` [ruby-core:104962] " ioquatix (Samuel Williams)
2021-08-18 17:04 ` [ruby-core:104971] " Eregon (Benoit Daloze)
2021-08-18 17:09 ` [ruby-core:104972] " Eregon (Benoit Daloze)
2021-08-18 23:04 ` [ruby-core:104980] " ioquatix (Samuel Williams)
2021-08-19  0:45 ` [ruby-core:104981] " duerst
2021-08-19  0:51 ` [ruby-core:104982] " ioquatix (Samuel Williams)
2021-08-19  1:00 ` [ruby-core:104984] " ioquatix (Samuel Williams)
2021-08-19  8:04 ` [ruby-core:105001] " ioquatix (Samuel Williams)
2021-08-19  8:19 ` [ruby-core:105002] " matz (Yukihiro Matsumoto)
2021-08-19  9:57 ` [ruby-core:105005] " ioquatix (Samuel Williams)
2021-08-19 16:42 ` [ruby-core:105013] " Eregon (Benoit Daloze)
2021-08-20  1:09 ` ioquatix (Samuel Williams) [this message]
2021-08-20 22:00 ` [ruby-core:105033] " Eregon (Benoit Daloze)
2021-08-20 22:03 ` [ruby-core:105034] " ioquatix (Samuel Williams)
2021-08-20 22:09 ` [ruby-core:105035] " Eregon (Benoit Daloze)
2021-08-21  0:52 ` [ruby-core:105036] " ioquatix (Samuel Williams)
2021-10-19  4:46 ` [ruby-core:105667] " ko1 (Koichi Sasada)
2021-10-19 17:51 ` [ruby-core:105682] " Eregon (Benoit Daloze)
2021-10-21  6:13 ` [ruby-core:105715] " ko1 (Koichi Sasada)
2021-10-21  6:28 ` [ruby-core:105716] " matz (Yukihiro Matsumoto)
2021-10-21 10:24 ` [ruby-core:105727] " Eregon (Benoit Daloze)
2021-10-21 11:15 ` [ruby-core:105728] " ioquatix (Samuel Williams)
2021-10-21 11:17 ` [ruby-core:105729] " ioquatix (Samuel Williams)
2021-10-21 13:00 ` [ruby-core:105733] " nobu (Nobuyoshi Nakada)
2023-12-14 19:40 ` [ruby-core:115747] " ioquatix (Samuel Williams) via ruby-core
2023-12-14 20:08 ` [ruby-core:115748] " kddnewton (Kevin Newton) via ruby-core
2023-12-15 14:46 ` [ruby-core:115752] " Dan0042 (Daniel DeLorme) via ruby-core
2023-12-15 20:15 ` [ruby-core:115755] " ioquatix (Samuel Williams) via ruby-core
2023-12-15 20:20 ` [ruby-core:115756] " jeremyevans0 (Jeremy Evans) via ruby-core
2023-12-15 20:30 ` [ruby-core:115757] " ioquatix (Samuel Williams) via ruby-core
2023-12-15 21:41 ` [ruby-core:115759] " Dan0042 (Daniel DeLorme) via ruby-core

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-93421.20210820010935.3344@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).