Abstract Methods and NotImplementedError in Ruby
nithinbekal.com
Abstract Methods and NotImplementedError in Ruby
1–10 of 26 posts
Re: Abstract Methods and NotImplementedError in Ruby
#2I think that NotImplementedError doesn't get rescued is a feature, not a bug. It means you are calling a class that has a missing part of the interface, and that's usually programmer error. For some cases where you can partially implement the spec, it may make sense to go this way, but for most abstract classes I think the NotImplementedError is still a good idea.
Re: Abstract Methods and NotImplementedError in Ruby
#3I think that NotImplementedError doesn't get rescued is a feature, not a bug. It means you are calling a class that has a missing part of the interface, and that's usually programmer error. For some cases where you can partially implement the spec, it may make sense to go this way, but for most abstract classes I think the NotImplementedError is still a good idea.
Yeah, an unimplemented abstract method being called shouldn't really ever happen at runtime and should be some form of "Internal Error" and should aggressively try to blow up the program. I think this blog post just convinced me using it is correct. The concrete class that leaves it unimplemented should raise something else if they intend to let consumers catch it with a generic rescue clause (which is probably a code smell itself).
Re: Abstract Methods and NotImplementedError in Ruby
#4I think that NotImplementedError doesn't get rescued is a feature, not a bug. It means you are calling a class that has a missing part of the interface, and that's usually programmer error. For some cases where you can partially implement the spec, it may make sense to go this way, but for most abstract classes I think the NotImplementedError is still a good idea.
I totally agree with this point of view
Re: Abstract Methods and NotImplementedError in Ruby
#5How about... and please sit down for this one... How about adding an "abstract" keyword for methods and refusing to compile with an abstract method from a parent class not being implemented in a non abstract child class?
Re: Abstract Methods and NotImplementedError in Ruby
#6How about... and please sit down for this one... How about adding an "abstract" keyword for methods and refusing to compile with an abstract method from a parent class not being implemented in a non abstract child class?
Or, you know, people use different programming languages for reasons and there isn't need to unify all the languages as one?
Re: Abstract Methods and NotImplementedError in Ruby
#7How about... and please sit down for this one... How about adding an "abstract" keyword for methods and refusing to compile with an abstract method from a parent class not being implemented in a non abstract child class?
It's Ruby, there's no compilation. It's also common to not load all files of an application's codebase at startup, in particular this is the default setting for Rails in development mode.
Re: Abstract Methods and NotImplementedError in Ruby
#8Ongoing related discussion: https://bugs.ruby-lang.org/issues/18915
Re: Abstract Methods and NotImplementedError in Ruby
#9Wow I didn't know this.
I and thusly our team uses `NotImplementedError` all over the place and I know I picked up that pattern from a rubygem somewhere along the line (predates copilot or generative code by years).
Even though I'm technically using it incorrectly, I don't want it to inherit `StandardError` and thus blows up. Because, I want it to blow up in the worst way possible. The handling engineer knows this is serious, and it if made it all the way to production, then our specs are lacking so bad that we need to have a discussion.
That's a feature to me.
Re: Abstract Methods and NotImplementedError in Ruby
#10How about... and please sit down for this one... How about adding an "abstract" keyword for methods and refusing to compile with an abstract method from a parent class not being implemented in a non abstract child class?
It's Ruby, there's no compilation. It's also common to not load all files of an application's codebase at startup, in particular this is the default setting for Rails in development mode.
There is. CRuby code gets compiled to ISeq (VM bytecode) upon `load` / `require` / `eval`. JRuby does similar things (IIRC using InvokeDynamic).
The difference (and that does not even need to involve Rails) is that these three - and thus compilation - happen at runtime, anytime, always.
The fact that a typical "main" file follows the "require first, then define modules and classes, then execute" creates a mental illusion of order; the fact that generally dependencies also follow this propagates that illusion across the board.
Therefore at the ruby source level you can only have runtime checks (and failure via exceptions), unless you bring in another static analysis tool such as Sorbet or RBS+Steep, which is an actual solution to enforce interface contracts without risking blowing up an app at runtime. That stays true even if there were a hypothetical "abstract" Ruby-level keyword. The only other solution without such tools is to have perfect (runtime) coverage via tests.
Note that mruby takes a fundamentally different approach here, and there's no require nor load.