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/50520cc1930331bccdb94730e17ddc…
raises NotImplementedError when a class needs provide its own <=> method.
-
[
delegate.rb](https://github.com/ruby/ruby/blob/c4d22d47f8bd019ae6df98fafb9d…
raises NotImplementedError to indicate that a __getobj__ and __setobj__ need to provided
by a subclass.
-
[
tsort](https://github.com/ruby/ruby/blob/6dcd39997679914dad1c23f95adb3f7d84…
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&…
- [minitest uses this
pattern](https://github.com/search?q=repo%3Aminitest%2Fminitest%20NotImplem…
- [rspec uses this
pattern](https://github.com/search?q=org%3Arspec%20NotImplementedError&…
- [dry-rb libraries use this
pattern](https://github.com/search?q=org%3Adry-rb+NotImplementedError&t…
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-dff1fd…
*
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-…
# 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/