Feature #14122: Add LogicError

• Status: Open
• Assignee: -
• Target version: -

[eike.rb (Eike Dierks)]

Dear friends at ruby

I'd like to suggest a new error for ruby-core: LogicError

That error should be thrown
upon operations that are detected to be illogic or impossible by semantics.
I believe that this could improve the error messages a lot.

Today we have:
1.to_enum - 2.to_enum
NoMethodError: undefined method `-' for #<Enumerator: 1:each>

Well, there are good reasons why #- is not implemented for Enumerator,
more so for (Enumerator - Enumerator)

Today this throws NoMethodError,
while I'd like to throw this a LogicError,
with an attached explanation,
that this operation simply does not make any sense.

But then, we should simply mark this as reserved (like private def)

---

I believe we can improve on the ease of using ruby
if we improve on the error messages

For the kids: NoMethodError is not that friendly,
(my kid tried to add and substract all and anything)

Don't get me wrong,
I am well aware about NoMethodErrors
(and how to reflect that on proxy APIs)

I'm asking for something different.

I want to explicitely raise a LogicError
for that operations that make no sense.

---

Alternate implementation:
StandardError#explain
because some of the errors that we detect can be explained.

[shevegen (Robert A. Heiler)]

I am not sure if this is a good new error "type".

Who defines what exactly is not about "logic" in these cases? Is
5 / 0 also a logic error? Or adding hash + array via the '+'?
Because that is "TypeError: no implicit conversion of Hash into
Array".

Then there is the issue of backwards compatibility. Even if we
say it were to target ruby 3.x, I assume that many people would
have to change their code, e. g. begin/rescue clause as an
example to adapt to this error rather than the one before for
the same operations. And what is the net gain, actually?

I don't really think that it would really add a lot of additional
usefulness to ruby. But that is only my personal opinion.

[duerst (Martin Dürst)]

For most method names, on most objects, one gets a NoMethodError. This error is produced by the method lookup part of the Ruby interpreter, at no cost to the implementers of particular classes. Changing that to a LogicError or whatever we call it would mean to add methods just to raise LogicError, which would add work for every class implementer and would bloat the binary.

Also, are there NoMethodErrors that are not LogicErrors? I can see three types:

1. Spelling errors (and for these, we have the did_you_mean gem).

2. Errors using the wrong word (e.g. remove instead of delete). Should we introduce a MethodNameError for these? It might be a lot of work to find all the wrong words that people might try.

3. Errors where a method might ("logically") exist, but isn't implemented yet. Should we introduce a NotYetImplemented error for these? Again, this might be quite a bit of work.

One good way to start might be to write a gem (call it e.g. beginners_error_messages), and see how far you get, and how popular the gem gets. Developing it may be easier with input from more than one beginning programmer. Online programming sites may be in a very good position to provide some data (all the programs that failed with a NoMethodError, in this case).

[jeremyevans0 (Jeremy Evans)]

• Tracker changed from Bug to Feature
• Backport deleted (2.3: UNKNOWN, 2.4: UNKNOWN)