From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [94.130.110.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id EC76D1F4BE for ; Tue, 29 Oct 2024 12:44:56 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=0f306K4e; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=X551MvAM; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1730205864; bh=+4Vh6nXBRLMASzIfuo1Wc5xHs1ua5wYgjdcEIgjs9O8=; h=Date:To:Reply-To:Subject:List-Id:List-Archive:List-Help: List-Owner:List-Post:List-Subscribe:List-Unsubscribe:From:Cc:From; b=0f306K4eiIx7BIQVkWxt1bh4m+zZwSJ9EWbPMLz1mQNnWWpO9331TqeDFzbqFgkqR 7sb9dR/SvZEd6j09LqRGtqZMopUfiM9YVStDXlUo7LsSSzYoM3AzhNEXEk2+6Z1++t bN1yLp7x3aYJ/TOQii9KGwIqy3wZosRLvPzSoX2M= Received: from nue.mailmanlists.eu (localhost [IPv6:::1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 739C744AA5 for ; Tue, 29 Oct 2024 12:44:24 +0000 (UTC) Authentication-Results: nue.mailmanlists.eu; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=X551MvAM; dkim-atps=neutral Received: from mail-oo1-f45.google.com (mail-oo1-f45.google.com [209.85.161.45]) by nue.mailmanlists.eu (Postfix) with ESMTPS id 9B62544A51 for ; Tue, 29 Oct 2024 12:44:05 +0000 (UTC) Received: by mail-oo1-f45.google.com with SMTP id 006d021491bc7-5ebc349204cso2827804eaf.3 for ; Tue, 29 Oct 2024 05:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730205784; x=1730810584; darn=ml.ruby-lang.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=MXK2u5iUg6hprL4Bgw5dUDN5+dZ/Irs4KCcddB7VJwI=; b=X551MvAMRPRa5Nq2xg4pfiMzZgJdRSMLk2CYSoialKHYP94Um3A9C+RwRo9GY7k30X qiQhbmdK2A4+miu+86I9FWair3HKWzkcn1ejQHghC/CIhDWWAOfXNrk0/5mpyrCUyeTx YBE1kEIapaMIU0qNSuLtY7WFV5VpOkkMRfVrfE08wa/oYdOi3oPlzqLRQ1+pgog6laXS aWNmHxKOHzd/GHQ57N/IG/0yLbS+qz3JmqMnlFupYE5OXxoo1FsTOwLTXO1Yxc4S2C0z 4UmZ3BvBisi/pdk2kvTsQctCY6Uc0YmADfT0MZMEkJKinYtiv4EHg93p7O0LeI6YCgNK LPIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730205784; x=1730810584; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=MXK2u5iUg6hprL4Bgw5dUDN5+dZ/Irs4KCcddB7VJwI=; b=FhGmuDPzCD4JLu+L9kPQiC8iJh+45cAe80fqA9StdixQlIdY+7aFYhB9qteZA+ohGM BbrB8s7zGrRrCDvasez13m2IVqizaNLkglmgpMZqEtGezYnqylULtUaXjC/vJkrX5CDs jFqroBS6W7eg4ZusK/gP3rmyLHIyzurjA5D4Ams7/qcqRc/93b9f3LQuYu5Oj+Hw7pS8 FYrwwJ0qT14ys7erucTVKhWHmxhRy0d7/TRJ496oj/ahXfjJvY38kZUQ+D/0Ki6TcDMX PIPvF/q0d6i6MVxyEnzhy94Mn59NqcHcaol263XGWBRUkgyhjCUNzK9Gt3YuXaIv2HTo zKZw== X-Gm-Message-State: AOJu0YxrjAQ4Yg/34UT2rPUUcwKroOJ326iPeT6jIlY7wdRisrR/71gD OBAjDeR88CHmjRwN+Ay/Sv3aQsymR9FhlybcHeYXRLzxe9uKHnzIzAm2df4FgXYcHRIN3QM0XaR as+ve0sbOEX0h4nIrp5/8FB6t7BDK6EmNOxYb5A== X-Google-Smtp-Source: AGHT+IFrtiL6hS4O//YBgeTP08NakXgrIyKzWcitvh59hWdBBK3ELH5sL3Zs7uJIyB++aG1WJnRHd/yzcaK8FdBdOhk= X-Received: by 2002:a05:6358:93a6:b0:1c3:7275:491 with SMTP id e5c5f4694b2df-1c3f9e2ac07mr372932755d.1.1730205784158; Tue, 29 Oct 2024 05:43:04 -0700 (PDT) MIME-Version: 1.0 Date: Tue, 29 Oct 2024 09:42:53 -0300 Message-ID: To: ruby-core@ml.ruby-lang.org Message-ID-Hash: 4IFDW24FACUOZMYJQZHHEMLM57B2RK67 X-Message-ID-Hash: 4IFDW24FACUOZMYJQZHHEMLM57B2RK67 X-MailFrom: rr.rosas@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:119637] Behavior of raising from rescue blocks when multiple rescue blocks exist List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: Rodrigo Rosenfeld Rosas via ruby-core Cc: Rodrigo Rosenfeld Rosas Content-Type: multipart/mixed; boundary="===============4822595560046292522==" --===============4822595560046292522== Content-Type: multipart/alternative; boundary="0000000000002739f906259cedf0" --0000000000002739f906259cedf0 Content-Type: text/plain; charset="UTF-8" Hello, I couldn't find any documentation about the subject, so I thought this behavior should be probably documented. Given the following code: def raise_error raise "runtime error message" rescue => e "StandardError: #{e.message}" rescue RuntimeError => e puts "RuntimeError raised: #{e.message}" raise StandardError, "standard error message" end # same, but the order of the rescue blocks are inverted def raise_error2 raise "runtime error message" rescue RuntimeError => e puts "RuntimeError raised: #{e.message}" raise StandardError, "standard error message" rescue => e "StandardError: #{e.message}" end p ["raise_error", raise_error ] begin p ["raise_error2", raise_error2] rescue => e puts "raise_error2 raised: #{e.message}" end When we run it, this is the output in Ruby 3.3.5: ["raise_error", "StandardError: runtime error message"] RuntimeError raised: runtime error message raise_error2 raised: standard error message In the first case (raise_error), the code raised from the RuntimeError rescue block is rescued by the StandardError block, but when inverting the order of the rescue blocks (raise_error2) then this won't happen. Is this part of the specs? Is this behavior documented somewhere? Could this behavior differ in different Ruby implementations and versions? Or can we rely on such behavior? This chapter doesn't include such case in its examples: https://ruby-doc.com/docs/ProgrammingRuby/html/tut_exceptions.html Or this documentation about Exceptions: https://ruby-doc.org/3.3.5/syntax/exceptions_rdoc.html Is there a recommended way for wrapping exceptions into a particular one and then handling that exception from within the same method rescue blocks? Or is this considered a bad practice? --0000000000002739f906259cedf0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello, I couldn't find any documentation about the sub= ject, so I thought this behavior should be probably documented.

Given the following code:

def raise= _error
=C2=A0 raise "runtime error message"
rescue =3D> = e
=C2=A0 "StandardError: #{e.message}"
rescue RuntimeError = =3D> e
=C2=A0 puts "RuntimeError raised: #{e.message}"
= =C2=A0 raise StandardError, "standard error message"
end
# same, but the order of the rescue blocks are inverted
def raise_erro= r2
=C2=A0 raise "runtime error message"
rescue RuntimeError= =3D> e
=C2=A0 puts "RuntimeError raised: #{e.message}"
= =C2=A0 raise StandardError, "standard error message"
rescue = =3D> e
=C2=A0 "StandardError: #{e.message}"
end

p= ["raise_error", raise_error ]

begin
=C2=A0 p ["ra= ise_error2", raise_error2]
rescue =3D> e
=C2=A0 puts "ra= ise_error2 raised: #{e.message}"
end

When we run it, this is= the output in Ruby 3.3.5:

["raise_error", "S= tandardError: runtime error message"]

RuntimeError raise= d: runtime error message

raise_error2 raised: standard error message


In the f= irst case (raise_error), the code raised from the RuntimeError rescue block= is rescued by the StandardError block, but when inverting the order of the= rescue blocks (raise_error2) then this won't happen.

Is this pa= rt of the specs? Is this behavior documented somewhere? Could this behavior= differ in different Ruby implementations and versions? Or can we rely on s= uch behavior?


This chapter doesn't include such case in it= s examples:

https://ruby-doc.com/docs/ProgrammingRuby/html/tut_e= xceptions.html

Or this documentation about Exceptions:

https://ru= by-doc.org/3.3.5/syntax/exceptions_rdoc.html

Is there a recommen= ded way for wrapping exceptions into a particular one and then handling tha= t exception from within the same method rescue blocks? Or is this considere= d a bad practice?


--0000000000002739f906259cedf0-- --===============4822595560046292522== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/ --===============4822595560046292522==--