Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I like to raise a NotImplementedError for any method that I want to implement, but where I haven't gotten around to doing it yet. I might already have a partial implementation, but prepend it with raise NotImplementedError() because I don't like it yet. On the other hand, I also like to stick to conventions, because this will make it easier for other people to maintain my code, and conventions might exist for a good reason.

However Pythons documentation for NotImplementedError states:

This exception is derived from RuntimeError. In user defined base classes, abstract methods should raise this exception when they require derived classes to override the method.

That is a much more specific, formal use case than the one I describe. Is it a good, conventional style to raise a NotImplementedError simply to indicate that this part of the API is a work in progress? If not, is there a different standardised way of indicating this?

share|improve this question
What do you mean by "appropriate?" –  Robert Harvey Mar 5 at 20:54
@RobertHarvey I suppose I mean conventional, following common usage. I have rephrased my question now. –  gerrit Mar 5 at 20:57
We use C# here primarily, but that sort of exception throwing is idiomatic here, and I would expect elsewhere. Break early and break loudly is a good guideline for identifying potential issues quickly (read: inexpensively). –  Telastyn Mar 5 at 20:57
Generally if I am creating a class I just put TODO comments in unimplemented methods until I get around to implementing the functionality. If the class were going to be released to production before that happened, I would consider throwing exceptions. –  John Gaughan Mar 5 at 21:15
For what it's worth, this is what Microsoft Visual Studio does by default when you use the IDE to "implement an interface." At Robert Harvey says, the result is well understood. –  catfood Mar 5 at 21:28

2 Answers 2

It's worth noting that, while the Python documentation provides a use case (and probably the canonical one) for this exception, it doesn't specifically exclude its use in other scenarios.

I would consider it appropriate to raise a NotImplementedError exception if you haven't overridden a method in a base class yet (to satisfy the "interface").

A cursory check on Google suggests that people will understand what you mean if you use the exception in this fashion. There are no side effects or unintended consequences that I know of; the method will simply throw an exception if it is called, and it will throw an exception that is well-understood by everyone.

share|improve this answer
+1, but I'd also add that for this kind of convention, a little documentation can go a long way. Like a one-line note in a dev wiki, repo readme, or style guideline -- something like that -- explaining what you use this exception for. –  Ben Lee Mar 10 at 20:43

This will be understood, whether you do it or not should depend on local (team or company) conventions. Note that it makes less sense in the context of TDD as the TEST should be what determines that the method isn't implemented.

The short version is: use if you and your team consider it appropriate.

share|improve this answer
FWIW, Throwing the exception should be a good way to get the test to fail, if for some reason you need to force that behavior. (It'd be useful as part of a method-definition intellisense stub, for example.) –  DougM Mar 5 at 21:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.