Issue #18915 has been updated by matz (Yukihiro Matsumoto). Thanks for the discussion, and thanks to @koic for summarizing what we talked about at RubyKaigi in Matsue. Let me settle the direction. The new exception class should inherit from `ScriptError`, not `StandardError`. Failing to define a method that a subclass is required to provide is a problem in the program itself, the same kind of problem as `SyntaxError` or `LoadError`, not a runtime error. `NotImplementedError` already inherits from `ScriptError`, so the new class becomes its natural sibling, and a clean migration target for the code that has been misusing `NotImplementedError`. This also resolves the concern raised earlier in this thread. Since it does not inherit from `StandardError`, a bare `rescue` will not swallow it and the mistake surfaces during development, while test frameworks that rescue `Exception` (such as Minitest) will still catch and report it. For the same reason I do not want to reuse `NoMethodError`, which inherits from `StandardError` and would be caught by a bare `rescue`. For the name, the candidates were `AbstractMethodError` (from Java) and `SubclassResponsibility` (from Smalltalk). `SubclassResponsibility` expresses the intent well, and the lack of an `Error` suffix would not be a problem by itself, since Ruby has exception classes such as `Interrupt` that do not end in `Error`. But because the closely related `NotImplementedError` has the `Error` suffix, I prefer to keep it consistent. Let's go with `AbstractMethodError`. Matz. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-117562 * 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/