Issue #18915 has been updated by koic (Koichi ITO). I had an opportunity to discuss this with @matz and @shyouhei at Matsue RubyKaigi 12, held on June 6, 2026. Below is a summary of that discussion. - Leave the current `NotImplementedError` unchanged for now. - Introduce a new exception class intended for cases where a method is expected to be defined in a subclass. - The new class should inherit from `ScriptError` (not `RuntimeError`), following the same rationale as `SyntaxError` and `LoadError`. It represents a problem with the script itself rather than a runtime error. - `SubclassResponsibility` (or `AbstractMethodError`) is a candidate name for the new `ScriptError` subclass. Additional context reflecting my understanding of the discussion, together with some personal observations. Instead of introducing a new exception class, it would also be possible to consider a different mechanism that results in a `NoMethodError`. However, there have been repeated instances of `NotImplementedError` being used in ways that do not match its intended purpose. Furthermore, AI-generated code is also sometimes seen using `NotImplementedError` incorrectly in this manner. Since this misuse of `NotImplementedError` is already widespread, the introduction of `SubclassResponsibility` would provide a migration path for such cases. For cases where `NotImplementedError` is currently being used incorrectly, the migration path would be to replace it with `SubclassResponsibility`. For existing code that is using `NotImplementedError` correctly, no changes would be necessary and those usages would remain as they are. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-117490 * 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-dff1fd7... * 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-y... # 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/