How to signal "not implemented yet"?

Question

In the initial drafting of a new gem I need to leave some method implementations empty ( to be implemented in the next )

Therefore, I would like to signal a "not implemented yet" exception

I'm wondering if there is a best practice or standard conventions specific to the Ruby language to code this kind of placeholder / exception.

i.e: something like:

• UnsupportedOperationException in Java
• NotImplementedException in .Net Framework (C#)

Solution 1

You should raise NotImplementedError

raise NotImplementedError

ruby-doc

Solution 2

You may use the todonotes-gem

There is a documentation with some examples.

It doesn't implement an exception, but a logging mechanism and a possibility for temporary solutions.

Solution 3

Looks like the original answer, which suggested raising NotImplementedError, was removed. I'll take a crack at it: write documentation.

Don't add code that's just a placeholder. You wouldn't want folks coding against that API so don't even give them a chance (yourself included). Instead, document the road map you are currently planning on in the class and/or README. Then be open to it changing. Odds are by the time you get around to solving whatever problem is in the road map you'll have new thoughts on what is the appropriate solution. I think this is the right course of action in any language/framework, but I think Ruby in particular encourages us to not write code that you don't plan on having executed.

Comments

[Franco Rondini]

This is good advice for the documentation, but what I meant in my question was for a sort of exceptions as in the answer given by @padde

[sawa]

Problem arises when a non-implemented method is used. If the existence of such method is not known, then such problem will not arise in the first place. And not documenting is enough the hide the existence. If you think the user is hackish enough to look into the source code to figure out such method, then you can simply write #TODO within that method in the source to notify that it is not implemented yet.

[Franco Rondini]

#TODO comments is a good practice that actually I follow of course; also in other development the IDE (cfr. eclipse) leverage this particular type of comments to report Warnings to the developer; I got used to doing it. btw I would like to better explain my question: saying In the initial drafting I mean a pre-release stage where the users are the same as the developers and we need a way to leave a Placeholder (i.e. method will be in the Class.methods , but if the implementation is not made at the end cause the failure of tests with track easily and immediately understandable.

[knut]

@FrancoRondini I published a new version (same functionality, but another filestructure and improved documentation)

[Sudhir Jonathan]

While doing this might work, it also sends the wrong message to the users of the gem / api - that there's a bug somewhere or that some code is trying to call the wrong method. In your case, the code is calling the correct method, but the method is supposed to be implemented separately. I'd suggest the NotImplementedError instead.

[josiah]

I'm in agreement with Sudhir. I don't have enough rep to down-vote, yet, but the Ruby Documentation says that NoMethodError is for undefined methods. In this case, however, you have a defined method with no implementation, making NoMethodError deceptive.

[Léo]

@Josiah, I also agree with @SudhirJonathan. I use NotImplementedError when writing abstract classes, however I tend to add a message explaining the error, for example: raise NotImplementedError, new("#{self.class.name} is an abstract class."). I found this method in books.google.com.au/…

[Ivan Kolmychek]

Just keep in mind, that, according to 2.3.0 documentation, NotImplementedError is not intended to use in that way, but it signals that feature is not implemented on the current platform. It also has the unusual inheritance chain ScriptError > Exception, where most of the exceptions are inherited from StandardError. You can probably create your own error to signify that and inherit it from StandardError and that may be even better.

[pasha.zhukov]

@IvanKolmychek what exception class should I use in case of feature is not implemented yet on current platform ?

[Ivan Kolmychek]

best way to do this that I see is to create your custom exception class that will inherit StandardError, so, it can be properly catched if needed. Here is why catching something other (like SyntaxError, from which NotImplementedError is inherited in 2.3.0) can be a bad idea: stackoverflow.com/questions/10048173/…

[GuyPaddock]

Although this addresses the OP's question, there is the related question of documenting required methods required by a sub-class. Though duck typing encourages no definition in the parent class (and, consequently, no docs), that's not maintainable on projects with multiple team members or projects that are going to be handed off to a third-party (e.g. API contracts).

[GuyPaddock]

Here's what the original answer (which has now been deleted) said. I felt this had some additional color on this that's now missing, for some reason. imgur.com/a/FSbVm

[fraxture]

NotImplementedError extends ScriptError and so won't be caught by begin..rescue. This is not the right error to use. See, e.g.: chrisstump.online/2016/03/23/stop-abusing-notimplementederro‌​r

[Alter Lagos]

I don't get why all the downvotes on this answer. It was already told on this comment, but NotImplementedError should be only used when a method is not implemented in the current platform, so what Jörg said in this answer is correct. And yeah, NotImplementedError could solve the issue for the OP, but it's also important what's the right thing to do.