# Use of NotImplementedException

Is it considered bad practice to throw NotImplementedException for code you haven't written yet? Possibly TODO comments would be considered safer?

-
What would be the downside of using such exceptions to you? –  SRKX Jan 4 '12 at 21:04
@SRKX There is the risk of exceptions getting into production code and causing the whole code block to not work. (hasnt happened to me yet but we all have off days) I personally use them, I was worried I could have overlooked some of the downsides. –  Tom Squires Jan 4 '12 at 21:37
Oddly enough, none of the tags specify which language is being used. This doesn't apply to every common language, as C doesn't have any sort of exceptions. There's room for a language tag here, guys. –  David Thornley Jan 4 '12 at 21:58
@DavidThornley, the question was originally tagged as C#, so I readded the tag. –  svick Jan 4 '12 at 22:17
@svick: Thought it was likely C#. Thanks for adding the tag. –  David Thornley Jan 4 '12 at 22:21

I believe NotImplementedException is actually a good practice.

Indeed, if you forget to implement a method, and you use it later on in your project (and believe me, it happens), you might spend a long time debugging looking for what went wrong step by step. If you have the exception, the program will stop directly, prompting the exception (if you catch the exception, you'll find it quickly by looking what exception you caught).

I would recommend using the NotImplementedException combined with TODO comments, that way you combine GUI help (with the tasks in VS) and program safety.

For the release version, it's even more important in my opinion, as in most cases you would prefer your program to crash rather than having a program apparently working properly but producing erroneous results.

-
If you use Resharper, it shows NotImplementedExceptions in the same way as TODO comments. I think that's a nice feature. –  svick Jan 4 '12 at 22:19
Throw in some good TDD practice and you've got a winner –  LRE Jan 4 '12 at 22:27

It depends on your general philosophy around errors and error handling. I am the "hard error" type of guy: I will throw an exception at the slightest hint that something might be wrong; I will assert everything; If there is an error, if something was expected to be there, and it is not, or if something is there, and it shouldn't, the entire universe must stop. The windows exclamation sound must ring ominously through the loudspeakers.

There are other people who would rather not be bothered with errors. So what if we ship it to the client and the entire reports module is missing because we forgot to code it, and nobody in testing realized it, because the application was all too silent about it? Better do nothing, than throw an exception in the client's face!

-
It is as if you would want different behavior in Debug and Release, and an assertion will not always cut it. I believe .Net Code Contracts can be turned off in Release. –  Job Jan 4 '12 at 21:21
I mostly use assertions, which are also turned off in release. I have my own assertion function which hits a breakpoint in debug, throws an exception when testing, or does not even compile on release. –  Mike Nakis Jan 4 '12 at 21:23

I'd say it's a good idea. Usually I see those exceptions thrown by skeleton code that is auto-generated from a form or diagram or something. The exception reminds me to implement the code, and it makes sure that there will be errors if I try to use the functionality that was set up but never fully implemented. Sometimes I will stub it out or replace it with something that is less likely to halt execution (such as printing a warning to the console), but I find that it works for me.

If you're building a library that others will be using having this exception is better than the alternative, which would be a user of your library calling a function and wondering why nothing seemed to happen. Of course, it's still pretty bad to have this exception in a shipped library but better than silent failures, IMO.

-

I think it's good practice. The alternative is propagating an invalid value or state, which is going to affect both test and production code.

-
Hold on.... you mean, where you work, code that throws NotImpl would make it all the way to QA? Even into production? –  Steve Evers Jan 4 '12 at 21:04
No, just the opposite: a NotImpl is a nice enormous red flag / error condition. But TODOs have no semantic value and can make it into test or production, quietly screwing things up. (I could imagine a policy of eliminating TODOs from production, but we don't have such a rule.) –  Larry OBrien Jan 4 '12 at 21:32

I always use NotImplementedException -- that's what it's for, after all.

This is related to the concept of "fail fast": if your code is throwing an exception, that should get caught before going to production. If it does get to production, then at least the client knows that the assembly is incorrect.

If the code returns a meaningless value or, for void methods, takes no action, then the consumers of your code might reasonably think that the call was meaningful when it was not. Then, later, when they get some correct code, their code might break because it depends on the former incorrect behavior.

-

What kind of project is this? Work or home? At home, do whatever you want - whatever best reminds you that you need to finish whatever it is that you're working on.

At work, finish writing it.

I can't see a situation where I would checkin code that can/will break other devs, QA or a build.

-
Well both, I try to adhere to good practices at home too. –  Tom Squires Jan 4 '12 at 21:13

I do both I but a \todo in my doxygene autodocing and then throw the exception. That way if people can't be bothered to RTFM at least they will be able to figure out why their program crashed, instead of wondering why there is a declared function that is not returning a logical value.

-