64

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:

Dave Newton
  • 158,873
  • 26
  • 254
  • 302
Franco Rondini
  • 10,841
  • 8
  • 51
  • 77
  • Clarification: In this pre-release stage we need a way to leave a *placeholder* (i.e. we want the method to be defined: it will be in the `self.methods` of the class we are writing ) but until the concrete implementation is made we need the failure of tests and a track easily and immediately understandable. – Franco Rondini Dec 02 '12 at 11:28

5 Answers5

32

You should raise NotImplementedError

raise NotImplementedError

ruby-doc

pasha.zhukov
  • 1,272
  • 10
  • 9
  • 28
    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. – Ivan Kolmychek Jun 15 '16 at 12:02
  • 1
    @IvanKolmychek what exception class should I use in case of `feature is not implemented yet on current platform` ? – pasha.zhukov Jun 16 '16 at 20:21
  • 1
    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: https://stackoverflow.com/questions/10048173/why-is-it-bad-style-to-rescue-exception-e-in-ruby – Ivan Kolmychek Jun 17 '16 at 08:58
  • 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. http://imgur.com/a/FSbVm – GuyPaddock Aug 31 '17 at 15:56
  • 1
    `NotImplementedError` extends `ScriptError` and so won't be caught by `begin..rescue`. This is not the right error to use. See, e.g.: http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/ – fraxture Apr 17 '20 at 19:58
4

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.

knut
  • 27,320
  • 6
  • 84
  • 112
  • 1
    @FrancoRondini I published a new version (same functionality, but another filestructure and improved documentation) – knut Dec 02 '12 at 22:02
1

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.

Chris
  • 1,826
  • 12
  • 15
  • 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 Aug 31 '17 at 15:13
-1

Do not mention the unimplemented methods in the documents, or mention that they are not implemented yet. That is all.

sawa
  • 165,429
  • 45
  • 277
  • 381
  • 1
    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 – Franco Rondini Dec 02 '12 at 09:48
  • 3
    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. – sawa Dec 02 '12 at 10:14
  • #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. – Franco Rondini Dec 02 '12 at 11:05
-18

Ruby will raise a NoMethodError for you anyway, when calling a non-existing method. That should be good enough for most cases.

Hack-R
  • 22,422
  • 14
  • 75
  • 131
Jörg W Mittag
  • 363,080
  • 75
  • 446
  • 653
  • 16
    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. – Sudhir Jonathan Jun 12 '13 at 04:51
  • 3
    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. – josiah Feb 25 '14 at 16:57
  • 7
    @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 http://books.google.com.au/books?id=bJkznhZBG6gC&pg=PA300&lpg=PA300&dq=ruby+NotImplementedError&source=bl&ots=AlQ2bbuZXI&sig=NAnUopr35Y5wT5CSfK9EUZNK8Qc&hl=en&sa=X&ei=24MnU_iBLuW1iAea2YGgAw&redir_esc=y#v=onepage&q=ruby%20NotImplementedError&f=false – Dom Mar 17 '14 at 23:40
  • 1
    I don't get why all the downvotes on this answer. It was already told on [this comment](https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-yet#comment63130968_37293953), 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. – Alter Lagos Nov 25 '20 at 02:13