Use of NotImplementedException

Question

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

Answer 1

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.

Answer 2

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!

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.