ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
* [ruby-core:93227] [Ruby trunk Feature#15936] on_error in lieu of rescue, raise
       [not found] <redmine.issue-15936.20190618182844@ruby-lang.org>
@ 2019-06-18 18:28 ` shout
  2019-06-18 22:23 ` [ruby-core:93230] " shevegen
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: shout @ 2019-06-18 18:28 UTC (permalink / raw
  To: ruby-core

Issue #15936 has been reported by kylemacey (Kyle Macey).

----------------------------------------
Feature #15936: on_error in lieu of rescue, raise
https://bugs.ruby-lang.org/issues/15936

* Author: kylemacey (Kyle Macey)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
A common bad pattern in ruby is to rescue any exception and accidentally clobber the exception. 

```
begin
  some_method
rescue StandardError
  # 
end
```

Most linters will complain if you write rescues like the code above. However, this could be useful if we want to perform an operation on _any_ error, as long as we re-raise the exception after doing our work.

```
begin
  some_method
rescue StandardError
  job.fail! 
  raise
end
```

Here, though, we run the risk of potentially forgetting to reraise the exception, or having to make exceptions in our linter for an operation that is overall benign.

What would be a thought on using another keyword that doesn't actually _rescue_ an exception, but performs an operation in the event of an error? Similar to `ensure`, but only in the event of an error.

```
begin
  some_method
on_error StandardError
  job.fail! 
end
```

(obviously, someone more creative than me should come up with a better name)



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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [ruby-core:93230] [Ruby trunk Feature#15936] on_error in lieu of rescue, raise
       [not found] <redmine.issue-15936.20190618182844@ruby-lang.org>
  2019-06-18 18:28 ` [ruby-core:93227] [Ruby trunk Feature#15936] on_error in lieu of rescue, raise shout
@ 2019-06-18 22:23 ` shevegen
  2019-06-19  1:56 ` [ruby-core:93237] " shout
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: shevegen @ 2019-06-18 22:23 UTC (permalink / raw
  To: ruby-core

Issue #15936 has been updated by shevegen (Robert A. Heiler).


Hmmm.

I have not made up my mind so I can not even say whether this may be interesting
or not.

But I think just a few general thoughts:

- People may expect begin/rescue/end, more than any alternatives. They may wonder
what on_error is or how it would be used (or any other name).

- Is it very common to use ensure/rescue/re-raise? I have no statistical data but
in my own code, but also in code by other people, it seems as if simple begin
rescue clauses are highly prevalent. This should not be assumed as a con opinion,
I am just pointing this out in context as to whether on_error would be worth 
to be added (and I honestly do not know).

As for potentially pro-points, if I understood one part of your issue correctly
then you also suggest being able to handle a specific error-case with this
line exactly. Or at the least this is how I understand the code example, where
in the second you can omit one line right?

These are just some semi-random comments from me - as I wrote above, I really
do not even have the slightest idea yet whether I may like, dislike or even
just be neutral on it. :)

----------------------------------------
Feature #15936: on_error in lieu of rescue, raise
https://bugs.ruby-lang.org/issues/15936#change-78680

* Author: kylemacey (Kyle Macey)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
A common bad pattern in ruby is to rescue any exception and accidentally clobber the exception. 

```
begin
  some_method
rescue StandardError
  # 
end
```

Most linters will complain if you write rescues like the code above. However, this could be useful if we want to perform an operation on _any_ error, as long as we re-raise the exception after doing our work.

```
begin
  some_method
rescue StandardError
  job.fail! 
  raise
end
```

Here, though, we run the risk of potentially forgetting to reraise the exception, or having to make exceptions in our linter for an operation that is overall benign.

What would be a thought on using another keyword that doesn't actually _rescue_ an exception, but performs an operation in the event of an error? Similar to `ensure`, but only in the event of an error.

```
begin
  some_method
on_error StandardError
  job.fail! 
end
```

(obviously, someone more creative than me should come up with a better name)



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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [ruby-core:93237] [Ruby trunk Feature#15936] on_error in lieu of rescue, raise
       [not found] <redmine.issue-15936.20190618182844@ruby-lang.org>
  2019-06-18 18:28 ` [ruby-core:93227] [Ruby trunk Feature#15936] on_error in lieu of rescue, raise shout
  2019-06-18 22:23 ` [ruby-core:93230] " shevegen
@ 2019-06-19  1:56 ` shout
  2019-06-19  2:31 ` [ruby-core:93239] " merch-redmine
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: shout @ 2019-06-19  1:56 UTC (permalink / raw
  To: ruby-core

Issue #15936 has been updated by kylemacey (Kyle Macey).


shevegen (Robert A. Heiler) wrote:
> Hmmm.
> 
> I have not made up my mind so I can not even say whether this may be interesting
> or not.
> 
> But I think just a few general thoughts:
> 
> - People may expect begin/rescue/end, more than any alternatives. They may wonder
> what on_error is or how it would be used (or any other name).


Yeah, this is a proposal to extend the available keywords in ruby core. So ideally, there would be release notes and documentation that would help guide people to this new feature.

> 
> - Is it very common to use ensure/rescue/re-raise? I have no statistical data but
> in my own code, but also in code by other people, it seems as if simple begin
> rescue clauses are highly prevalent. This should not be assumed as a con opinion,
> I am just pointing this out in context as to whether on_error would be worth 
> to be added (and I honestly do not know).

This is coming from a need that I personally face often on the utilities I work on, where I need to update state on an object if something unexpected happens. My company's linter gets upset when I use the `rescue StandardError` pattern, so I was hoping to have a way to be more explicit that I'm not trying to prevent the error from going up the stack, I just want to act upon the exception.

> 
> As for potentially pro-points, if I understood one part of your issue correctly
> then you also suggest being able to handle a specific error-case with this
> line exactly. Or at the least this is how I understand the code example, where
> in the second you can omit one line right?

Yeah, there's the nicety of being able to reduce a line, but even more enticing is how explicit this pattern feels, and how it can be less error-prone (by forgetting to reraise, or by accidentally casting too wide of a `rescue` net).

> 
> These are just some semi-random comments from me - as I wrote above, I really
> do not even have the slightest idea yet whether I may like, dislike or even
> just be neutral on it. :)



----------------------------------------
Feature #15936: on_error in lieu of rescue, raise
https://bugs.ruby-lang.org/issues/15936#change-78687

* Author: kylemacey (Kyle Macey)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
A common bad pattern in ruby is to rescue any exception and accidentally clobber the exception. 

```
begin
  some_method
rescue StandardError
  # 
end
```

Most linters will complain if you write rescues like the code above. However, this could be useful if we want to perform an operation on _any_ error, as long as we re-raise the exception after doing our work.

```
begin
  some_method
rescue StandardError
  job.fail! 
  raise
end
```

Here, though, we run the risk of potentially forgetting to reraise the exception, or having to make exceptions in our linter for an operation that is overall benign.

What would be a thought on using another keyword that doesn't actually _rescue_ an exception, but performs an operation in the event of an error? Similar to `ensure`, but only in the event of an error.

```
begin
  some_method
on_error StandardError
  job.fail! 
end
```

(obviously, someone more creative than me should come up with a better name)



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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [ruby-core:93239] [Ruby trunk Feature#15936] on_error in lieu of rescue, raise
       [not found] <redmine.issue-15936.20190618182844@ruby-lang.org>
                   ` (2 preceding siblings ...)
  2019-06-19  1:56 ` [ruby-core:93237] " shout
@ 2019-06-19  2:31 ` merch-redmine
  2019-06-19  7:15 ` [ruby-core:93242] " duerst
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: merch-redmine @ 2019-06-19  2:31 UTC (permalink / raw
  To: ruby-core

Issue #15936 has been updated by jeremyevans0 (Jeremy Evans).


kylemacey (Kyle Macey) wrote:
> What would be a thought on using another keyword that doesn't actually _rescue_ an exception, but performs an operation in the event of an error? Similar to `ensure`, but only in the event of an error.
> 
> ```
> begin
>   some_method
> on_error StandardError
>   job.fail! 
> end
> ```

Thankfully, Ruby already supports what you want:

```ruby
begin
  some_method
ensure
  job.fail! if $! # or use case $! if you want to handle specific exception classes differently
end
```

As you can already accomplish this with current Ruby syntax, I do not think adding a keyword for it is warranted.

----------------------------------------
Feature #15936: on_error in lieu of rescue, raise
https://bugs.ruby-lang.org/issues/15936#change-78689

* Author: kylemacey (Kyle Macey)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
A common bad pattern in ruby is to rescue any exception and accidentally clobber the exception. 

```
begin
  some_method
rescue StandardError
  # 
end
```

Most linters will complain if you write rescues like the code above. However, this could be useful if we want to perform an operation on _any_ error, as long as we re-raise the exception after doing our work.

```
begin
  some_method
rescue StandardError
  job.fail! 
  raise
end
```

Here, though, we run the risk of potentially forgetting to reraise the exception, or having to make exceptions in our linter for an operation that is overall benign.

What would be a thought on using another keyword that doesn't actually _rescue_ an exception, but performs an operation in the event of an error? Similar to `ensure`, but only in the event of an error.

```
begin
  some_method
on_error StandardError
  job.fail! 
end
```

(obviously, someone more creative than me should come up with a better name)



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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [ruby-core:93242] [Ruby trunk Feature#15936] on_error in lieu of rescue, raise
       [not found] <redmine.issue-15936.20190618182844@ruby-lang.org>
                   ` (3 preceding siblings ...)
  2019-06-19  2:31 ` [ruby-core:93239] " merch-redmine
@ 2019-06-19  7:15 ` duerst
  2019-06-20 19:17 ` [ruby-core:93286] " shout
  2019-06-20 19:18 ` [ruby-core:93287] " shout
  6 siblings, 0 replies; 8+ messages in thread
From: duerst @ 2019-06-19  7:15 UTC (permalink / raw
  To: ruby-core

Issue #15936 has been updated by duerst (Martin Dürst).


kylemacey (Kyle Macey) wrote:

> This is coming from a need that I personally face often on the utilities I work on, where I need to update state on an object if something unexpected happens. My company's linter gets upset when I use the `rescue StandardError` pattern, so I was hoping to have a way to be more explicit that I'm not trying to prevent the error from going up the stack, I just want to act upon the exception.

What about getting the linter to recognize that you are using `raise` again in the `rescue` clause? That shouldn't be too difficult, at least for the simple cases.


----------------------------------------
Feature #15936: on_error in lieu of rescue, raise
https://bugs.ruby-lang.org/issues/15936#change-78693

* Author: kylemacey (Kyle Macey)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
A common bad pattern in ruby is to rescue any exception and accidentally clobber the exception. 

```
begin
  some_method
rescue StandardError
  # 
end
```

Most linters will complain if you write rescues like the code above. However, this could be useful if we want to perform an operation on _any_ error, as long as we re-raise the exception after doing our work.

```
begin
  some_method
rescue StandardError
  job.fail! 
  raise
end
```

Here, though, we run the risk of potentially forgetting to reraise the exception, or having to make exceptions in our linter for an operation that is overall benign.

What would be a thought on using another keyword that doesn't actually _rescue_ an exception, but performs an operation in the event of an error? Similar to `ensure`, but only in the event of an error.

```
begin
  some_method
on_error StandardError
  job.fail! 
end
```

(obviously, someone more creative than me should come up with a better name)



-- 
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>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [ruby-core:93286] [Ruby trunk Feature#15936] on_error in lieu of rescue, raise
       [not found] <redmine.issue-15936.20190618182844@ruby-lang.org>
                   ` (4 preceding siblings ...)
  2019-06-19  7:15 ` [ruby-core:93242] " duerst
@ 2019-06-20 19:17 ` shout
  2019-06-21 18:54   ` [ruby-core:93304] " Austin Ziegler
  2019-06-20 19:18 ` [ruby-core:93287] " shout
  6 siblings, 1 reply; 8+ messages in thread
From: shout @ 2019-06-20 19:17 UTC (permalink / raw
  To: ruby-core

Issue #15936 has been updated by kylemacey (Kyle Macey).


jeremyevans0 (Jeremy Evans) wrote:
> kylemacey (Kyle Macey) wrote:
> > What would be a thought on using another keyword that doesn't actually _rescue_ an exception, but performs an operation in the event of an error? Similar to `ensure`, but only in the event of an error.
> > 
> > ```
> > begin
> >   some_method
> > on_error StandardError
> >   job.fail! 
> > end
> > ```
> 
> Thankfully, Ruby already supports what you want:
> 
> ```ruby
> begin
>   some_method
> ensure
>   job.fail! if $! # or use case $! if you want to handle specific exception classes differently
> end
> ```
> 
> As you can already accomplish this with current Ruby syntax, I do not think adding a keyword for it is warranted.

`ensure` fires even if there is no exception. This keyword would only fire when there is an exception. In your example, `job.fail!` would always be called.

----------------------------------------
Feature #15936: on_error in lieu of rescue, raise
https://bugs.ruby-lang.org/issues/15936#change-78754

* Author: kylemacey (Kyle Macey)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
A common bad pattern in ruby is to rescue any exception and accidentally clobber the exception. 

```
begin
  some_method
rescue StandardError
  # 
end
```

Most linters will complain if you write rescues like the code above. However, this could be useful if we want to perform an operation on _any_ error, as long as we re-raise the exception after doing our work.

```
begin
  some_method
rescue StandardError
  job.fail! 
  raise
end
```

Here, though, we run the risk of potentially forgetting to reraise the exception, or having to make exceptions in our linter for an operation that is overall benign.

What would be a thought on using another keyword that doesn't actually _rescue_ an exception, but performs an operation in the event of an error? Similar to `ensure`, but only in the event of an error.

```
begin
  some_method
on_error StandardError
  job.fail! 
end
```

(obviously, someone more creative than me should come up with a better name)



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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [ruby-core:93287] [Ruby trunk Feature#15936] on_error in lieu of rescue, raise
       [not found] <redmine.issue-15936.20190618182844@ruby-lang.org>
                   ` (5 preceding siblings ...)
  2019-06-20 19:17 ` [ruby-core:93286] " shout
@ 2019-06-20 19:18 ` shout
  6 siblings, 0 replies; 8+ messages in thread
From: shout @ 2019-06-20 19:18 UTC (permalink / raw
  To: ruby-core

Issue #15936 has been updated by kylemacey (Kyle Macey).


duerst (Martin Dürst) wrote:
> kylemacey (Kyle Macey) wrote:
> 
> > This is coming from a need that I personally face often on the utilities I work on, where I need to update state on an object if something unexpected happens. My company's linter gets upset when I use the `rescue StandardError` pattern, so I was hoping to have a way to be more explicit that I'm not trying to prevent the error from going up the stack, I just want to act upon the exception.
> 
> What about getting the linter to recognize that you are using `raise` again in the `rescue` clause? That shouldn't be too difficult, at least for the simple cases.

Very true! I can certainly do that, I just thought this might have the added benefit of writing more explicit and intentional code, and would eliminate the need to re-raise the exception.

----------------------------------------
Feature #15936: on_error in lieu of rescue, raise
https://bugs.ruby-lang.org/issues/15936#change-78755

* Author: kylemacey (Kyle Macey)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
A common bad pattern in ruby is to rescue any exception and accidentally clobber the exception. 

```
begin
  some_method
rescue StandardError
  # 
end
```

Most linters will complain if you write rescues like the code above. However, this could be useful if we want to perform an operation on _any_ error, as long as we re-raise the exception after doing our work.

```
begin
  some_method
rescue StandardError
  job.fail! 
  raise
end
```

Here, though, we run the risk of potentially forgetting to reraise the exception, or having to make exceptions in our linter for an operation that is overall benign.

What would be a thought on using another keyword that doesn't actually _rescue_ an exception, but performs an operation in the event of an error? Similar to `ensure`, but only in the event of an error.

```
begin
  some_method
on_error StandardError
  job.fail! 
end
```

(obviously, someone more creative than me should come up with a better name)



-- 
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>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [ruby-core:93304] Re: [Ruby trunk Feature#15936] on_error in lieu of rescue, raise
  2019-06-20 19:17 ` [ruby-core:93286] " shout
@ 2019-06-21 18:54   ` Austin Ziegler
  0 siblings, 0 replies; 8+ messages in thread
From: Austin Ziegler @ 2019-06-21 18:54 UTC (permalink / raw
  To: Ruby developers


[-- Attachment #1.1: Type: text/plain, Size: 2885 bytes --]

No, the `ensure` line is `job.fail! if $!`. That adds a conditional to the
`ensure`.

On Thu, Jun 20, 2019 at 3:17 PM <shout@kylemacey.com> wrote:

> Issue #15936 has been updated by kylemacey (Kyle Macey).
>
>
> jeremyevans0 (Jeremy Evans) wrote:
> > kylemacey (Kyle Macey) wrote:
> > > What would be a thought on using another keyword that doesn't actually
> _rescue_ an exception, but performs an operation in the event of an error?
> Similar to `ensure`, but only in the event of an error.
> > >
> > > ```
> > > begin
> > >   some_method
> > > on_error StandardError
> > >   job.fail!
> > > end
> > > ```
> >
> > Thankfully, Ruby already supports what you want:
> >
> > ```ruby
> > begin
> >   some_method
> > ensure
> >   job.fail! if $! # or use case $! if you want to handle specific
> exception classes differently
> > end
> > ```
> >
> > As you can already accomplish this with current Ruby syntax, I do not
> think adding a keyword for it is warranted.
>
> `ensure` fires even if there is no exception. This keyword would only fire
> when there is an exception. In your example, `job.fail!` would always be
> called.
>
> ----------------------------------------
> Feature #15936: on_error in lieu of rescue, raise
> https://bugs.ruby-lang.org/issues/15936#change-78754
>
> * Author: kylemacey (Kyle Macey)
> * Status: Open
> * Priority: Normal
> * Assignee:
> * Target version:
> ----------------------------------------
> A common bad pattern in ruby is to rescue any exception and accidentally
> clobber the exception.
>
> ```
> begin
>   some_method
> rescue StandardError
>   #
> end
> ```
>
> Most linters will complain if you write rescues like the code above.
> However, this could be useful if we want to perform an operation on _any_
> error, as long as we re-raise the exception after doing our work.
>
> ```
> begin
>   some_method
> rescue StandardError
>   job.fail!
>   raise
> end
> ```
>
> Here, though, we run the risk of potentially forgetting to reraise the
> exception, or having to make exceptions in our linter for an operation that
> is overall benign.
>
> What would be a thought on using another keyword that doesn't actually
> _rescue_ an exception, but performs an operation in the event of an error?
> Similar to `ensure`, but only in the event of an error.
>
> ```
> begin
>   some_method
> on_error StandardError
>   job.fail!
> end
> ```
>
> (obviously, someone more creative than me should come up with a better
> name)
>
>
>
> --
> 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>
>


-- 
Austin Ziegler • halostatue@gmail.com • austin@halostatue.ca
http://www.halostatue.ca/http://twitter.com/halostatue

[-- Attachment #1.2: Type: text/html, Size: 4132 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2019-06-21 18:54 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <redmine.issue-15936.20190618182844@ruby-lang.org>
2019-06-18 18:28 ` [ruby-core:93227] [Ruby trunk Feature#15936] on_error in lieu of rescue, raise shout
2019-06-18 22:23 ` [ruby-core:93230] " shevegen
2019-06-19  1:56 ` [ruby-core:93237] " shout
2019-06-19  2:31 ` [ruby-core:93239] " merch-redmine
2019-06-19  7:15 ` [ruby-core:93242] " duerst
2019-06-20 19:17 ` [ruby-core:93286] " shout
2019-06-21 18:54   ` [ruby-core:93304] " Austin Ziegler
2019-06-20 19:18 ` [ruby-core:93287] " shout

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).