[ruby-core:109207] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedYet

[ruby-core:109207] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedYet

[Quintasan]

Issue #18915 has been reported by Quintasan (Michał Zając).

----------------------------------------
Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedYet
https://bugs.ruby-lang.org/issues/18915

* Author: Quintasan (Michał Zając)
* Status: Open
* Priority: Normal
----------------------------------------
# Abstract

Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedYet` to cover those usecases so we don't have to introduce another exception

# Background

`NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html)

However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing). However I have seen this being discussed numerous times:

* https://github.com/rubocop/ruby-style-guide/issues/458
* http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/
* https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd7228e5
* https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of)
* https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedYet`)
* https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-yet

# Proposal

Create `NotImplementedYetError` exception

OR

Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities

# Evaluation

### Add `NotImplementedYetError`

I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception.

### Change scope of `NotImplementedYet`

This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever.



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

[ruby-core:110770] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError

[austin (Austin Ziegler)]

Issue #18915 has been updated by austin (Austin Ziegler).


I think that a PR for a documentation change on this would probably be accepted.

----------------------------------------
Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError
https://bugs.ruby-lang.org/issues/18915#change-100115

* Author: Quintasan (Michał Zając)
* Status: Open
* Priority: Normal
----------------------------------------
# Abstract

Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception

# Background

`NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html)

However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing). However I have seen this being discussed numerous times:

* https://github.com/rubocop/ruby-style-guide/issues/458
* http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/
* https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd7228e5
* https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of)
* https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`)
* https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-yet

# Proposal

Create `NotImplementedYetError` exception

OR

Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities

# Evaluation

### Add `NotImplementedYetError`

I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception.

### Change scope of `NotImplementedError`

This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever.



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

[ruby-core:114937] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError

[zdennis (Zach Dennis) via ruby-core]

Issue #18915 has been updated by zdennis (Zach Dennis).

File not-implemented-error-docs.patch added

Attached is a patch to update the documentation for NotImplementedError to expand its scope beyond just missing features on the underlying platform.

The current documentation has been in place since just before Ruby 1.9.2. Historically, it appears that Ruby hasn't limited its usage of NotImplementedError to errors that originate from features missing from the underlying platform (e.g. system calls) since at least 1.8.0. I believe the example provided in the current NotImplementedError documentation was meant as an example, not to suggest the only scope in which this error can be used.

Ruby itself invalidates most of the interpretation provided in the Background section of this ticket. Here are just three examples:

- [numeric.c](https://github.com/ruby/ruby/blob/50520cc1930331bccdb94730e17ddc01798f2be0/numeric.c#L4700) raises NotImplementedError when a class needs provide its own  <=> method.
- [delegate.rb](https://github.com/ruby/ruby/blob/c4d22d47f8bd019ae6df98fafb9db7c20c33d30c/lib/delegate.rb#L184-L198) raises NotImplementedError to indicate that a __getobj__ and __setobj__  need to provided by a subclass.
- [tsort](https://github.com/ruby/ruby/blob/6dcd39997679914dad1c23f95adb3f7d84ec5942/lib/tsort.rb#L440-L454) uses this error and documents it expressly as: Should be implemented by a extended class.

There are more examples to be found in Ruby as well.

Outside of Ruby, this pattern is also commonly used as a way to communicate the intent to an application, framework, or library developer. Here are four examples from popular projects:

- [rails uses this pattern](https://github.com/search?q=org%3Arails%20NotImplementedError&type=code)
- [minitest uses this pattern](https://github.com/search?q=repo%3Aminitest%2Fminitest%20NotImplementedError&type=code)
- [rspec uses this pattern](https://github.com/search?q=org%3Arspec%20NotImplementedError&type=code)
- [dry-rb libraries use this pattern](https://github.com/search?q=org%3Adry-rb+NotImplementedError&type=code)

Additionally, even the latest Programming Ruby 3.2 book by PragPub uses an example of this in Chapter 6: Inheritance and Messages.

----------------------------------------
Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError
https://bugs.ruby-lang.org/issues/18915#change-104811

* Author: Quintasan (Michał Zając)
* Status: Open
* Priority: Normal
----------------------------------------
# Abstract

Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception

# Background

`NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html)

However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing). However I have seen this being discussed numerous times:

* https://github.com/rubocop/ruby-style-guide/issues/458
* http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/
* https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd7228e5
* https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of)
* https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`)
* https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-yet

# Proposal

Create `NotImplementedYetError` exception

OR

Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities

# Evaluation

### Add `NotImplementedYetError`

I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception.

### Change scope of `NotImplementedError`

This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever.

---Files--------------------------------
not-implemented-error-docs.patch (0 Bytes)


-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 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/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:114938] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError

[zdennis (Zach Dennis) via ruby-core]

Issue #18915 has been updated by zdennis (Zach Dennis).

File not-implemented-error-docs.patch added

Whoops, last patch upload failed. Patch actually applied here.

----------------------------------------
Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError
https://bugs.ruby-lang.org/issues/18915#change-104812

* Author: Quintasan (Michał Zając)
* Status: Open
* Priority: Normal
----------------------------------------
# Abstract

Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception

# Background

`NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html)

However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing). However I have seen this being discussed numerous times:

* https://github.com/rubocop/ruby-style-guide/issues/458
* http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/
* https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd7228e5
* https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of)
* https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`)
* https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-yet

# Proposal

Create `NotImplementedYetError` exception

OR

Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities

# Evaluation

### Add `NotImplementedYetError`

I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception.

### Change scope of `NotImplementedError`

This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever.

---Files--------------------------------
not-implemented-error-docs.patch (0 Bytes)
not-implemented-error-docs.patch (1.57 KB)


-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 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/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:114941] Re: [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError

[Алдан Муханов via ruby-core]

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

🙂👍

пн, 2 окт. 2023 г. в 19:12, zdennis (Zach Dennis) via ruby-core <
ruby-core@ml.ruby-lang.org>:

> Issue #18915 has been updated by zdennis (Zach Dennis).
>
> File not-implemented-error-docs.patch added
>
> Whoops, last patch upload failed. Patch actually applied here.
>
> ----------------------------------------
> Feature #18915: New error class: NotImplementedYetError or scope change
> for NotImplementedError
> https://bugs.ruby-lang.org/issues/18915#change-104812
>
> * Author: Quintasan (Michał Zając)
> * Status: Open
> * Priority: Normal
> ----------------------------------------
> # Abstract
>
> Introduce `NotImplementedYetError` exception that should be used in case
> when the codepath has not been implemented by the developer for some reason
> (maybe they're designing an abstract class or are designing some sort of
> interface to reuse later on) OR extend the meaning of `NotImplementedError`
> to cover those usecases so we don't have to introduce another exception
>
> # Background
>
> `NotImplementedError` is supposed to be raised `if the underlying
> operating system or Ruby runtime does not support them` (
> https://ruby-doc.org/core-3.1.2/NotImplementedError.html)
>
> However it appears that many people are misusing this exception by raising
> this in a superclass from which they later inherit from. I do realize that
> Ruby promotes duck-typing (the default RuboCop style guide has a cop for
> this – https://github.com/rubocop/ruby-style-guide#duck-typing). However
> I have seen this being discussed numerous times:
>
> * https://github.com/rubocop/ruby-style-guide/issues/458
> * http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/
> *
> https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd7228e5
> * https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the
> author of)
> * https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author
> actually confused it with Python's `NotImplementedError`)
> *
> https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-yet
>
> # Proposal
>
> Create `NotImplementedYetError` exception
>
> OR
>
> Allow raising `NotImplementedError` in cases other than OS or Ruby runtime
> incompatibilities
>
> # Evaluation
>
> ### Add `NotImplementedYetError`
>
> I think a new exception is a better idea than changing the usage of an
> existing one just because "everyone is using it". That said it would
> require people to refactor their code which might prevent wider adoption of
> the new exception.
>
> ### Change scope of `NotImplementedError`
>
> This would require the least amount of changes possible (only a
> documentation change) and I believe there would be no compatibility
> problems whatsoever.
>
> ---Files--------------------------------
> not-implemented-error-docs.patch (0 Bytes)
> not-implemented-error-docs.patch (1.57 KB)
>
>
> --
> https://bugs.ruby-lang.org/
>  ______________________________________________
>  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/postorius/lists/ruby-core.ml.ruby-lang.org/

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

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

 ______________________________________________
 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/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:115043] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError

[tenderlovemaking (Aaron Patterson) via ruby-core]

Issue #18915 has been updated by tenderlovemaking (Aaron Patterson).


I'm guilty of using `NotImplementedError` for abstract classes.  I like the idea of changing the documentation, but on the other hand, since `NotImplementedError` doesn't inherit from StandardError I kind of wish there was a new exception class.

----------------------------------------
Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError
https://bugs.ruby-lang.org/issues/18915#change-104917

* Author: Quintasan (Michał Zając)
* Status: Open
* Priority: Normal
----------------------------------------
# Abstract

Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception

# Background

`NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html)

However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing). However I have seen this being discussed numerous times:

* https://github.com/rubocop/ruby-style-guide/issues/458
* http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/
* https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd7228e5
* https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of)
* https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`)
* https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-yet

# Proposal

Create `NotImplementedYetError` exception

OR

Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities

# Evaluation

### Add `NotImplementedYetError`

I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception.

### Change scope of `NotImplementedError`

This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever.

---Files--------------------------------
not-implemented-error-docs.patch (1.57 KB)


-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 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/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:115045] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError

[Quintasan via ruby-core]

Issue #18915 has been updated by Quintasan (Michał Zając).


tenderlovemaking (Aaron Patterson) wrote in #note-8:
> I'm guilty of using `NotImplementedError` for abstract classes.  I like the idea of changing the documentation, but on the other hand, since `NotImplementedError` doesn't inherit from StandardError I kind of wish there was a new exception class.

Hence my proposal to introduce a new class. I didn't want to create a PR for either solution because I would welcome both of them. I'm slightly leaning towards a new exception class for this.

----------------------------------------
Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError
https://bugs.ruby-lang.org/issues/18915#change-104919

* Author: Quintasan (Michał Zając)
* Status: Open
* Priority: Normal
----------------------------------------
# Abstract

Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception

# Background

`NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html)

However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing). However I have seen this being discussed numerous times:

* https://github.com/rubocop/ruby-style-guide/issues/458
* http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/
* https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd7228e5
* https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of)
* https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`)
* https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-yet

# Proposal

Create `NotImplementedYetError` exception

OR

Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities

# Evaluation

### Add `NotImplementedYetError`

I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception.

### Change scope of `NotImplementedError`

This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever.

---Files--------------------------------
not-implemented-error-docs.patch (1.57 KB)


-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 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/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:115046] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError

[byroot (Jean Boussier) via ruby-core]

Issue #18915 has been updated by byroot (Jean Boussier).


> since NotImplementedError doesn't inherit from StandardError I kind of wish there was a new exception class

Could you elaborate? For this use case I think not inheriting from `StandardError` is better, as it's not something you'd want to be rescued broadly. 

----------------------------------------
Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError
https://bugs.ruby-lang.org/issues/18915#change-104920

* Author: Quintasan (Michał Zając)
* Status: Open
* Priority: Normal
----------------------------------------
# Abstract

Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception

# Background

`NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html)

However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing). However I have seen this being discussed numerous times:

* https://github.com/rubocop/ruby-style-guide/issues/458
* http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/
* https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd7228e5
* https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of)
* https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`)
* https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-yet

# Proposal

Create `NotImplementedYetError` exception

OR

Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities

# Evaluation

### Add `NotImplementedYetError`

I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception.

### Change scope of `NotImplementedError`

This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever.

---Files--------------------------------
not-implemented-error-docs.patch (1.57 KB)


-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 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/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:115048] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError

[tenderlovemaking (Aaron Patterson) via ruby-core]

Issue #18915 has been updated by tenderlovemaking (Aaron Patterson).


byroot (Jean Boussier) wrote in #note-10:
> > since NotImplementedError doesn't inherit from StandardError I kind of wish there was a new exception class
> 
> Could you elaborate? For this use case I think not inheriting from `StandardError` is better, as it's not something you'd want to be rescued broadly.

It is something I would like rescued broadly.  For example if I'm test driving a concrete implementation, the test framework needs to specifically rescue `NotImplementedError` in order to report the error.  I wouldn't expect a test framework to rescue OutOfMemoryError for example, but definitely rescue NotImplementedError.

----------------------------------------
Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError
https://bugs.ruby-lang.org/issues/18915#change-104922

* Author: Quintasan (Michał Zając)
* Status: Open
* Priority: Normal
----------------------------------------
# Abstract

Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception

# Background

`NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html)

However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing). However I have seen this being discussed numerous times:

* https://github.com/rubocop/ruby-style-guide/issues/458
* http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/
* https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd7228e5
* https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of)
* https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`)
* https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-yet

# Proposal

Create `NotImplementedYetError` exception

OR

Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities

# Evaluation

### Add `NotImplementedYetError`

I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception.

### Change scope of `NotImplementedError`

This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever.

---Files--------------------------------
not-implemented-error-docs.patch (1.57 KB)


-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 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/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:115049] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError

[byroot (Jean Boussier) via ruby-core]

Issue #18915 has been updated by byroot (Jean Boussier).


> I wouldn't expect a test framework to rescue OutOfMemoryError for example,

Well Minitest does rescue Exception:
https://github.com/minitest/minitest/blob/6719ad8d8d49779669083f5029ea9a0429c49ff5/lib/minitest/test.rb#L196

Pretty sure RSpec does as well. It's one of the rare justifiable cases for doing so.

----------------------------------------
Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError
https://bugs.ruby-lang.org/issues/18915#change-104923

* Author: Quintasan (Michał Zając)
* Status: Open
* Priority: Normal
----------------------------------------
# Abstract

Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception

# Background

`NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html)

However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing). However I have seen this being discussed numerous times:

* https://github.com/rubocop/ruby-style-guide/issues/458
* http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/
* https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd7228e5
* https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of)
* https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`)
* https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-yet

# Proposal

Create `NotImplementedYetError` exception

OR

Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities

# Evaluation

### Add `NotImplementedYetError`

I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception.

### Change scope of `NotImplementedError`

This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever.

---Files--------------------------------
not-implemented-error-docs.patch (1.57 KB)


-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 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/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:115297] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError

[mame (Yusuke Endoh) via ruby-core]

Issue #18915 has been updated by mame (Yusuke Endoh).


Discussed at the dev meeting. This is tentative, but @matz said:

* I don't want to change the documentation of `NotImplementedError`.
* `NotImplementedYetError` is too confusing with `NotImplementedError`.
* `ToBeDefinedError` or something would be better.
* I will reply to the ticket.

Please wait for matz's answer.

----------------------------------------
Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError
https://bugs.ruby-lang.org/issues/18915#change-105215

* Author: Quintasan (Michał Zając)
* Status: Open
* Priority: Normal
----------------------------------------
# Abstract

Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception

# Background

`NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html)

However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing). However I have seen this being discussed numerous times:

* https://github.com/rubocop/ruby-style-guide/issues/458
* http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/
* https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd7228e5
* https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of)
* https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`)
* https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-yet

# Proposal

Create `NotImplementedYetError` exception

OR

Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities

# Evaluation

### Add `NotImplementedYetError`

I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception.

### Change scope of `NotImplementedError`

This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever.

---Files--------------------------------
not-implemented-error-docs.patch (1.57 KB)


-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 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/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:115804] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError

[matz (Yukihiro Matsumoto) via ruby-core]

Issue #18915 has been updated by matz (Yukihiro Matsumoto).


#note-13 explains my opinion well. What name candidate do you have?

Matz.


----------------------------------------
Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError
https://bugs.ruby-lang.org/issues/18915#change-105753

* Author: Quintasan (Michał Zając)
* Status: Open
* Priority: Normal
----------------------------------------
# Abstract

Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception

# Background

`NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html)

However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing). However I have seen this being discussed numerous times:

* https://github.com/rubocop/ruby-style-guide/issues/458
* http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/
* https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd7228e5
* https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of)
* https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`)
* https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-yet

# Proposal

Create `NotImplementedYetError` exception

OR

Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities

# Evaluation

### Add `NotImplementedYetError`

I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception.

### Change scope of `NotImplementedError`

This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever.

---Files--------------------------------
not-implemented-error-docs.patch (1.57 KB)


-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 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/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:115814] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError

[Quintasan via ruby-core]

Issue #18915 has been updated by Quintasan (Michał Zając).


matz (Yukihiro Matsumoto) wrote in #note-14:
> #note-13 explains my opinion well. What name candidate do you have?
> 
> Matz.

How about `AbstractMethodError` - the same as Java?

----------------------------------------
Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError
https://bugs.ruby-lang.org/issues/18915#change-105763

* Author: Quintasan (Michał Zając)
* Status: Open
* Priority: Normal
----------------------------------------
# Abstract

Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception

# Background

`NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html)

However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing). However I have seen this being discussed numerous times:

* https://github.com/rubocop/ruby-style-guide/issues/458
* http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/
* https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd7228e5
* https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of)
* https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`)
* https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-yet

# Proposal

Create `NotImplementedYetError` exception

OR

Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities

# Evaluation

### Add `NotImplementedYetError`

I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception.

### Change scope of `NotImplementedError`

This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever.

---Files--------------------------------
not-implemented-error-docs.patch (1.57 KB)


-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 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/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:115861] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError

[Dan0042 (Daniel DeLorme) via ruby-core]

Issue #18915 has been updated by Dan0042 (Daniel DeLorme).


How about `raise NoMethodError, "method '#{__method__}' is not implemented in #{self.class}"`

----------------------------------------
Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError
https://bugs.ruby-lang.org/issues/18915#change-105819

* Author: Quintasan (Michał Zając)
* Status: Open
* Priority: Normal
----------------------------------------
# Abstract

Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception

# Background

`NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html)

However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing). However I have seen this being discussed numerous times:

* https://github.com/rubocop/ruby-style-guide/issues/458
* http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/
* https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd7228e5
* https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of)
* https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`)
* https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-yet

# Proposal

Create `NotImplementedYetError` exception

OR

Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities

# Evaluation

### Add `NotImplementedYetError`

I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception.

### Change scope of `NotImplementedError`

This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever.

---Files--------------------------------
not-implemented-error-docs.patch (1.57 KB)


-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 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/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:115862] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError

[byroot (Jean Boussier) via ruby-core]

Issue #18915 has been updated by byroot (Jean Boussier).


> How about raise NoMethodError

Agreed. If people want an exception that inherits from `StandardError`, then `NoMethodError` perfectly fits the bill.

I still think that "you forgot to implement this abstract method" shouldn't inherit from `StandardError` though, as it risk getting handled by the application and not surface during testing, hence why `NotImplementedError` already works great for that use case regardless of what the documentation says.

Amusingly Python has the same error class for that purpose exactly: https://docs.python.org/3/library/exceptions.html#NotImplementedError

>  exception NotImplementedError

>    This exception is derived from RuntimeError. In user defined base classes, abstract methods should raise this exception when they require derived classes to override the method, or while the class is being developed to indicate that the real implementation still needs to be added.

----------------------------------------
Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError
https://bugs.ruby-lang.org/issues/18915#change-105820

* Author: Quintasan (Michał Zając)
* Status: Open
* Priority: Normal
----------------------------------------
# Abstract

Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception

# Background

`NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html)

However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing). However I have seen this being discussed numerous times:

* https://github.com/rubocop/ruby-style-guide/issues/458
* http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/
* https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd7228e5
* https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of)
* https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`)
* https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-yet

# Proposal

Create `NotImplementedYetError` exception

OR

Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities

# Evaluation

### Add `NotImplementedYetError`

I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception.

### Change scope of `NotImplementedError`

This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever.

---Files--------------------------------
not-implemented-error-docs.patch (1.57 KB)


-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 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/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:117484] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError

[nithinbekal (Nithin Bekal) via ruby-core]

Issue #18915 has been updated by nithinbekal (Nithin Bekal).


> What name candidate do you have?

What do you think about the name `SubclassResponsibilityError`? As @citizen428 explains [here](https://ruby.social/@citizen428@chaos.social/112239323523258221):

> Smalltalk had the idiom of implementing abstract methods with the body `self subclassResponsibility` which raises an error.

The name gives a pretty clear indication of what is wrong, and it seems fitting considering Ruby's Smalltalk heritage.

----------------------------------------
Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError
https://bugs.ruby-lang.org/issues/18915#change-107873

* Author: Quintasan (Michał Zając)
* Status: Open
----------------------------------------
# Abstract

Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception

# Background

`NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html)

However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing). However I have seen this being discussed numerous times:

* https://github.com/rubocop/ruby-style-guide/issues/458
* http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/
* https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd7228e5
* https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of)
* https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`)
* https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-yet

# Proposal

Create `NotImplementedYetError` exception

OR

Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities

# Evaluation

### Add `NotImplementedYetError`

I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception.

### Change scope of `NotImplementedError`

This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever.

---Files--------------------------------
not-implemented-error-docs.patch (1.57 KB)


-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 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/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:117604] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError

[Dan0042 (Daniel DeLorme) via ruby-core]

Issue #18915 has been updated by Dan0042 (Daniel DeLorme).


It's a bit off-topic but does anyone know why NotImplementedError doesn't inherit from StandardError? It seems like it should. If the system doesn't support `fork()` then I'd like to see that as a nice message via Rack::ShowExceptions rather than having to dig through logs.
And if you use it for abstract classes then you *definitely* want that displayed by Rack::ShowExceptions

----------------------------------------
Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError
https://bugs.ruby-lang.org/issues/18915#change-108013

* Author: Quintasan (Michał Zając)
* Status: Open
----------------------------------------
# Abstract

Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception

# Background

`NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html)

However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing). However I have seen this being discussed numerous times:

* https://github.com/rubocop/ruby-style-guide/issues/458
* http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/
* https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd7228e5
* https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of)
* https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`)
* https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-yet

# Proposal

Create `NotImplementedYetError` exception

OR

Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities

# Evaluation

### Add `NotImplementedYetError`

I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception.

### Change scope of `NotImplementedError`

This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever.

---Files--------------------------------
not-implemented-error-docs.patch (1.57 KB)


-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 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/postorius/lists/ruby-core.ml.ruby-lang.org/