Why does NotImplementedException exist?

Question

This really, really urks me, so I hope that someone can give me a reasonable justification for why things are as they are.

NotImplementedException. You are pulling my leg, right?

No, I'm not going to take the cheap stab at this by saying, "hang on, the method is implemented - it throws a NotImplementedException." Yes, that's right, you have to implement the method to throw a NotImplementedException (unlike a pure virtual function call in C++ - now that makes sense!). While that's pretty damn funny, there is a more serious problem in my mind.

I just wonder, in the presence of the NotImplementedException, how can anyone do anything with .Net? Are you expected to wrap every abstract method call with a try catch block to guard against methods that might not be implemented? If you catch such an exception, what the heck are you supposed to do with it??

I see no way to test if a method is actually implemented without calling it. Since calling it may have side effects, I can't do all my checks up-front and then run my algorithm. I have to run my algorithm, catch NotImplementedExceptions and the some how roll back my application to some sane state.

It's crazy. Mad. Insane. So the question is: Why does the NotImplementedException exist?

As a preemptive strike, I do not want anyone to respond with, "because designers need to put this in the auto-generated code." This is horrid. I would rather the auto-generated code not compile until you supply an implementation. For example, the auto generated implementation could be "throw NotImplementedException;" where the NotImplementedException is not defined!

Has anyone ever caught and handled a NotImplementedException? Have you ever left a NotImplementedException in your code? If so, did this represent a time bomb (ie, you accidentally left it there), or a design flaw (the method should not be implemented and will never be called)?

I'm very suspicious of the NotSupportedException also... Not supported? What the? If it's not supported, why is it part of your interface? Can anyone at Microsoft spell improper inheritance? But I might start another question for that if I don't get too abuse for this one.

Additional info:

This is an interesting read on the subject.

There seems to be a strong agreement with Brad Abrams that "NotImplementedException is for functionality that is just not yet implemented, but really should (and will be). Something like what you might start with when you are building a class, get all the methods there throwing NotImplementedException, then flush them out with real code…"

Comments from Jared Parsons are very weak and should probably be ignored: NotImplementedException: Throw this exception when a type does not implement a method for any other reason.

The MSDN is even weaker on the subject, merely stating that, "The exception that is thrown when a requested method or operation is not implemented."

Solution 1

There is one situation I find it useful: TDD.

I write my tests, then I create stubs so the tests compile. Those stubs do nothing but throw new NotImplementedException();. This way the tests will fail by default, no matter what. If I used some dummy return value, it might generate false positives. Now that all tests compile and fail because there is no implementation, I tackle those stubs.

Since I never use a NotImplementedException in any other situation, no NotImplementedException will ever pass onto release code, since it will always make some test fail.

You don't need to catch it all over the place. Good APIs document the exceptions thrown. Those are the ones you should look for.

EDIT: I wrote an FxCop rule to find them.

This is the code:

using System;
using Microsoft.FxCop.Sdk;

/// <summary>
/// An FxCop rule to ensure no <see cref="NotImplementedException"/> is
/// left behind on production code.
/// </summary>
internal class DoNotRaiseNotImplementedException : BaseIntrospectionRule
{
    private TypeNode _notImplementedException;
    private Member _currentMember;

    public DoNotRaiseNotImplementedException()
        : base("DoNotRaiseNotImplementedException",
               // The following string must be the assembly name (here
               // Bevonn.CodeAnalysis) followed by a dot and then the
               // metadata file name without the xml extension (here
               // DesignRules). See the note at the end for more details.
               "Bevonn.CodeAnalysis.DesignRules",
               typeof (DoNotRaiseNotImplementedException).Assembly) { }

    public override void BeforeAnalysis()
    {
        base.BeforeAnalysis();
        _notImplementedException = FrameworkAssemblies.Mscorlib.GetType(
            Identifier.For("System"),
            Identifier.For("NotImplementedException"));
    }

    public override ProblemCollection Check(Member member)
    {
        var method = member as Method;
        if (method != null)
        {
            _currentMember = member;
            VisitStatements(method.Body.Statements);
        }
        return Problems;
    }

    public override void VisitThrow(ThrowNode throwInstruction)
    {
        if (throwInstruction.Expression != null &&
            throwInstruction.Expression.Type.IsAssignableTo(_notImplementedException))
        {
            var problem = new Problem(
                GetResolution(),
                throwInstruction.SourceContext,
                _currentMember.Name.Name);
            Problems.Add(problem);
        }
    }
}

And this is the rule metadata:

<?xml version="1.0" encoding="utf-8" ?>
<Rules FriendlyName="Bevonn Design Rules">
  <Rule TypeName="DoNotRaiseNotImplementedException" Category="Bevonn.Design" CheckId="BCA0001">
    <Name>Do not raise NotImplementedException</Name>
    <Description>NotImplementedException should not be used in production code.</Description>
    <Url>http://stackoverflow.com/questions/410719/notimplementedexception-are-they-kidding-me</Url>
    <Resolution>Implement the method or property accessor.</Resolution>
    <MessageLevel Certainty="100">CriticalError</MessageLevel>
    <Email></Email>
    <FixCategories>NonBreaking</FixCategories>
    <Owner></Owner>
  </Rule>
</Rules>

To build this you need to:

• reference Microsoft.FxCop.Sdk.dll and Microsoft.Cci.dll

• Put the metadata in a file called DesignRules.xml and add it as an embedded resource to your assembly

• Name your assembly Bevonn.CodeAnalysis. If you want to use different names for either the metadata or the assembly files, make sure you change the second parameter to the base constructor accordingly.

Then simply add the resulting assembly to your FxCop rules and take those damned exceptions out of your precious code. There are some corner cases where it won't report a NotImplementedException when one is thrown but I really think you are hopeless if you're actually writing such cthulhian code. For normal uses, i.e. throw new NotImplementedException();, it works, and that is all that matters.

Solution 2

It's there to support a fairly common use case, a working but only partially completed API. Say I want to developers to test and evaluate my API - WashDishes() works, at least on my machine, but I haven't gotten around yet to coding up DryDishes(), let alone PutAwayDishes(). Rather than silently failing, or giving some cryptic error message, I can be quite clear about why DryDishes() doesn't work - I haven't implemented it yet.

Its sister exception NotSupportedException make sense mostly for provider models. Many dishwashers have a drying function, so belongs in the interface, but my discount dishwasher doesn't support it. I can let that be known via the NotSupportedException

Solution 3

I'll summarize my views on this in one place, since they're scattered throughout a few comments:

1. You use NotImplementedException to indicate that an interface member isn't yet implemented, but will be. You combine this with automated unit testing or QA testing to identify features which still need to be implemented.

2. Once the feature is implemented, you remove the NotImplementedException. New unit tests are written for the feature to ensure that it works properly.

3. NotSupportedException is generally used for providers that don't support features that don't make sense for specific types. In those cases, the specific types throw the exception, the clients catch them and handle them as appropriate.

4. The reason that both NotImplementedException and NotSupportedException exist in the Framework is simple: the situations that lead to them are common, so it makes sense to define them in the Framework, so that developers don't have to keep redefining them. Also, it makes it easy for clients to know which exception to catch (especially in the context of a unit test). If you have to define your own exception, they have to figure out which exception to catch, which is at the very least a counter-productive time sink, and frequently incorrect.

Solution 4

Why does the NotImplementedException exist?

NotImplementedException is a great way to say that something is not ready yet. Why it's not ready is a separate question for method's authors. In production code you're unlikely to catch this exception, but if you did you can immediately see what happened and it's much better than trying to figure out why methods was called but nothing happened or even worse - receive some "temporary" result and get "funny" side effects.

Is NotImplementedException the C# equivalent of Java's UnsupportedOperationException?

No, .NET has NotSupportedException

I have to run my algorithm, catch NotImplementedExceptions and the some how roll back my application to some sane state

Good API has XML methods documentation that describes possible exceptions.

I'm very suspicious of the NotSupportedException also... Not supported? What the? If it's not supported, why is it part of your interface?

There can be millions reasons. For example you can introduce new version of API and don't want to/can't support old methods. Again, it is much better to see descriptive exception rather then digging into documentation or debugging 3rd party code.

Solution 5

The main use for a NotImplementedException exception is in generated stub code: that way you don't forget to implement it!! For example, Visual Studio will explicitly implement an interface's methods/properties with the body throwing a NotImplementedException.

View more solutions

Comments

[Daniel Paull]

So, it should never make it into production code? Then why is it part of the .net core? If you want this concept, then just "throw new Object();" with a comment stating that the method is pending implementation.

[Daniel Paull]

BTW - I'll give you +1 because you'd prefer to use something other than the exception. Personally I'd drop in an assert( false ) and a dummy return value, assuming I need the code to compile.

[Mitch Wheat]

@Daniel Paull : but surely that is more dangerous, because the assertions won't be compiled into Release code?...

[Mitch Wheat]

@Daniel Paull: the exception that's thrown!

[Daniel Paull]

But why is it a system exception? Why cant you throw your own exception? Why has MS made this part of the .net core? As for the dishwasher without the dry function - why does it have a dry method? Improper inheritance.

[Daniel Paull]

Ok, so there should be a Mone.NotImplementedException - why is it part of the .net core? If you avoid improper inheritance, an object is what it says it is, so the "can you do this?" / "do this" are redundant.

[Mitch Wheat]

@Daniel Paull: in fact you've jogged my memory, and I can recall a situation where exactly that happened...

[Daniel Paull]

If you program by contract, test your system and prove correctness, asserts are just dandy. The alternative just seems like a wing and a prayer. I am a massive advocate of asserts and getting your design right. It shouldn't be luck that makes your system work.

[aku]

There is an Obsolete attribute, I wish we have something like NotImplemented attribute to get compile-time warnings.

[Daniel Paull]

It sure smells like improper inheritance.

[R. Martinho Fernandes]

Why would you rather write your exception for such a situation?

[Øyvind Skaar]

I agree completely. Throwing this in any other setting is like having an "Under Construction" sign on your web page.

[Daniel Paull]

If used as merely as a placeholder, Why is NotImplementedException part of the .net core? I'd prefer this concept to be vendor specific and I would conditionally compile out my NotImplementedException in all public release builds. This is not a concept for the .net core.

[Daniel Paull]

An interface method that can never be called? What the heck?

[Daniel Paull]

Nice. However, Why is NotImplementedException part of the .net core? I'd prefer this concept to be vendor specific and I would conditionally compile out my NotImplementedException in all public release builds. This is not a concept for the .net core.

[Mitch Wheat]

@Daniel Paull: and an assertion suffers from the same problem.

[Daniel Paull]

@aku: excellent comment - this addresses the issue of not being able to tell if a method is actually implemented before calling it (not that one should ever have to do that).

[Daniel Paull]

because then I can remove it completely from release builds to avoid accidentally leaving one in the code.

[Daniel Paull]

@Mitch: assertions are a tool to test conditions that can not (by design) occur in your system - any assertion that is tripped indicates a programming error. Exceptions indicate runtime circumstances that do not (necessarily) indicate programming errors. Apples and oranges.

[R. Martinho Fernandes]

What causes damage in it being there? For me, it saves me the time of writing a dumb exception. And with my approach, I don't need to compile it out. I can guarantee it is never used in release code. And it sure doesn't make the framework much larger...

[Daniel Paull]

"so why spend your time coding something you won't even use?" Interesting - it seems that you have implemented stubs that you may never actually implement. Follow your own advice and you wont need the NotImplementedException!

[R. Martinho Fernandes]

Even though I use the exception a lot (see my answer), I would rather like that attribute thingy, especially if I could turn it into an aspect that throws an exception(NotImplemented being my first choice, for clarity).

[R. Martinho Fernandes]

Ok, I give it to you that it being an exception may not be the best solution. I would prefer the aspect idea.

[R. Martinho Fernandes]

I once went nuts when I realized had to write my own parser. That's really bad.

[Daniel Paull]

@Martinho: yeah baby, you're coming round.

[Daniel Paull]

Not just "bad", but inexcusable.

[R. Martinho Fernandes]

A Daniel said, you should not write stubs for no use. If you "may" need them in the future, write them in the future. Most of the time, .NET assemblies version very well.

[R. Martinho Fernandes]

If you don't implement the whole interface, don't implement it. With that methodology, you should use languages that can duck type, like Python or even c#4 :(.

[Daniel Paull]

You have no such freedom when all the standard tools auto generate code that has stubs that throw the NotImplementedException! You're also stuck if third party assemblies use it.

[hachu]

@Daniel: Combine the NotImplemented feature with TDD to ensure that a feature gets implemented; once the feature is implemented, remove the exception. It never gets to release code. A NotSupportedException is for providers, and is well documented, and SHOULD be caught by clients.

[Daniel Paull]

"makes it easier to find and eradicate them" - easier? That's your reason? Not because it's the right way to do it, but because it's the easy way to do it. Nice one man.

[Daniel Paull]

Why does a stream than does not support random access have a seek method? Lets not hide behind Microsoft's poor stream interface design.

[Daniel Paull]

I'm now scared of calling Reset() an any enumerator.

[Daniel Paull]

@Mike: if it's never used in released code, why is it in the .net core? If it never gets into released code, it need not be documented nor caught by anyone. PS: your tone is just fine with me! It's hard to remain all soft and squishy in 300 chars.

[krosenvold]

You can use "find usages" in your IDE for notimplementedexception. That's why

[dalle]

Sure an INotResetEnumerator would perhaps be better, which the IEnumerator derives from. But the leads to too many classes.

[Daniel Paull]

You admit that the NotImplementedException will be removed - if this is the case, there is no need for it in the .net core. It's your own private concern of your own private development process.

[krosenvold]

@Daniell Paull It's really nice to have this in the .net core because it presents a standardised, unformed way that I can do "find usages" in my IDE to identify unfinished stuff.

[Daniel Paull]

Why not have a "Microsoft.Development.Support" or similar assembly that has useful classes and utilities (including NotImplementedException). The intent is to reference that assembly in dev builds, but not in released code?

[Daniel Paull]

@krosenvold: That's why? An IDE feature dictating platform design? Sounds backwards to me.

[Daniel Paull]

@krosenvold: An IDE feature dictating platform design? Sounds backwards to me.

[Daniel Paull]

It would be interesting to design it properly. I disagree that it would lead to too many interfaces.

[Daniel Paull]

have a look at this list: blogs.msdn.com/brada/archive/2004/07/29/201354.aspx#203896

[dalle]

It all depends on the granularity, you could have IListMutable (which contains Add, Clear, Insert, Remove, RemoveAt) and IListImmutable (Contains, CopyTo, GetEnumerator, IndexOf). MyList : IListMutable, IListImmutable { /*impl*/ }

[dalle]

But what if you want an add only and readonly list? MyList : IListAdd, IListInsert, IListImmutable { /*impl*/ } and let IListMutable : IListAdd, IListClear, IListInsert, IListRemove, IListRemoveAt

[dalle]

Java UnsupportedOperationException could also be .NET InvalidOperationException.

[R. Martinho Fernandes]

@krosenvold: You could do "find usages" with XYZException. It would work the same. You just would need to write XYZException yourself.

[dalle]

An NotImplemented attribute would only work if the class is directly (and not calling the method using an interface)

[dalle]

@Daniel Paull: NotImplementedException is part of the core because people are lazy, if it didn't exist they would use Exception, NotSupportedException, InvalidOperationException, or some other exception instead.

[Djonatas Tenfen]

So you got 10 classes implements an interface but one of them or couple of them has got extra methods that you need to call. What's the way to do it? I do implement the interface with an extra method and call it if the type matches. What's you solution? 10 separate classes?

[Daniel Paull]

@Slough: give me an example where this is the case and I'll fix your design free of charge.

[oefe]

This would require adding the Microsoft.Development.Support assembly reference to each project that is using it, creating another inconvenience and hurdle for tools.

[Daniel Paull]

The interface for mutating abstract types is always going to be tricky and should be designed very carefully. Dare we ask if a square is-a rectangle?

[Daniel Paull]

Even better would be for the interface to have no delete() method. The interfaces sounds as broken as .net streams.

[Daniel Paull]

This is a very strange answer. If no one is ever meant to catch the exception, why would one ever throw it and why is it part of the .Net core? NOTE: just because you throw an exception doesn't mean it won't be caught. Why not just Assert(false) in both debug and release builds?

[Daniel Paull]

@Mike: I feel your pain, and this scenario may be valid as your hand has been forced. So MS included this bad exception to support their poor interface and framework design. Reasonable argument. I think that in this case, two wrongs just made things worse.

[jeroenh]

What would you do in the catch clause? Specifically for NotImplementedException?

[Daniel Paull]

If I had my way, I would never throw nor catch the NotImplementedException. I am trying to find a case for it being part of the core library.

[Daniel Paull]

And the problem with this is? I'd rather have my system correct that have a minor inconvenience for my developers. It would be more convenient to do way with DLLs, but the benefit justifies the cost (by cost I mean effort and complexity).

[orip]

@Daniel, I guess we have different opinions about it, but I would definitely not compile out the exceptions in release builds, just like I wouldn't catch a NullReferenceException - I'd fix the bug.

[Daniel Paull]

If the only valid use is to map to COM's E_NOTIMPL, then this exception should surely be in the interop namespace. What other valid uses are sited on that blog? The argument that it is to indicate a transient state of development is poor; use your own exception for that.

[Spodi]

"Follow your own advice and you wont need the NotImplementedException!" The point of the exception here is that you can compile while still fail if the method is called, and know why your code failed. Add the code if you get the exception - simple as that.

[Daniel Paull]

@orip: I think you misread. Compile out the NotImplementedException class, not the places it's used. This would force any stray uses of the NotImplementedException to become compile errors.

[Daniel Paull]

Why not throw your own exception type? Why is this a .net core concept?

[orip]

@Daniel: ah, that makes sense.

[Zach Snow]

It sounds like you're suggesting that the designer of any interface should always be able to guess all of the uses to which the interface might be put, in the manner of an oracle. Sure, within a single project this might be possible; in general I rather think not.

[Daniel Paull]

@zacharyrsnow: If one follows sound object oriented design principals then the interfaces will be intuitive and serve a clear purpose. Since the purpose is clear, no super powers (like an oracle) is required during desing. So, in general I rather think so...

[Jeffrey Hantin]

.Net's InvalidOperationException corresponds more closely to Java's IllegalStateException.

[Doctor Blue]

If you're working in interfaces that are "too general" for a class you're writing, you should probably consider an interface that only has the methods you actually want. If IFooBar has three methods and I have an instance of IFooBar, those methods better be implemented (or at least only throw contractually-defined exceptions). I'd say that 95% of the time or more throwing a NotImplementedException() would be a violation of the Liskov Substitution Principle.

[David R Tribble]

Yes, but sometimes you don't have a choice, like when you're using the standard .NET library. Consider some of the "optional" methods in the iterator and I/O streams classes.

[Daniel Paull]

"According to your logic you would need to remove the method off the interface and comment out non-compiling stub code." Let's not put words in my mouth - I would never suggest you do this. I agree that you will have unimplemented stubs during developent. But those stubs could throw your own exception. I just don't see why the NotImplementedException should exist as part of the .Net core libraries.

[Daniel Paull]

@S. DePouw: It might not violate the Liskov Substitution Principle if there is another way to determine if the method should be called at runtime, like a CanXXX() test that tells you that you can call XXX(). However, I am highly suspicious of these sort of interfaces as they smell like improper inhertance - as does (2) in this answer.

[Igor Zevaka]

Well in that case you did a common StackOverflow and didn't ask what you really wanted to ask. Your own answer answers your question quite succintly, but I, and I am sure, others read your question as "You shouldn't be throwing exceptions for unimplemented methods."

[Grhm]

I love the idea of using FxCop to double check that no NotImplementedExceptions remain. I've used it against one my projects and found one minor error. In VisitThrow you need to check that throwInstruction.Expression is not null. This occurs whenever someone rethrows via a bare "throw;" instruction. Other than that, great thanks!

[Daniel Paull]

catch( Exception ), or the analogous catch( ... ) in C++ is one on the most evil things you can do in programming. It's called "sweeping it under the carpet" and starts your descent into a Big Ball of Mud. Putting catch( Exception ) anywhere is not simple nor handy - if you think it is, then you have a long way to go before you can write robust code. In your example, if FullName is considered immutable (ie, can not be set), why does the API have a setter for it? Something is wrong with your (or Microsoft's) design. There are a myriad of ways you could avoid adding that setter...

[bambams]

catch(Exception) is exactly what you want at the "top" of the application where if the exception were otherwise left unhandled the run-time would have to handle it instead, which is generally ugly and unpleasant for a user. It's essentially a crash. Examples are within Main or within Page_Load. The FullName property has a setter because the serialization API requires it, as I said in the post you commented on...

[Saim Rahdari]

Why throw your own exceptions when there is a standard for it? Reeinventing the wheel is one of the main reasons why working in "our" industry is sometimes such a pain (NIH syndrome...) There are some places where you will need stubs, and throwing a standardized exception lets you track these easily with tools like "grep" for example. I also use NIE's a lot with TDD as well. There are a lot of places where they make sense. Just leaving off the stub is sometimes even more dangerous, I like to spam my code with "//TODO:"s because once its written down I cant forget it.

[Admin]

What you can do is search all your code for NotImplementedExceptions and make sure you find zero when you release.

[Alex from Jitbit]

@aku - Yes, mate. Thats what they have in Java. Java-devs can call a static method "Trace" like this NotImplementedException.Trace("warning!! not implemented!!"); I envy javists

[supercat]

@dalle: The proper design would have been to have IEnumerable not provide reset, but provide fairly loose guarantees about enumeration behavior when the collection is updated (throwing an exception would be an option, but not required, if all items that exist throughout the enumeration are returned exactly once, etc.); IMultipassEnumerable would add Reset, FastCount, and Count (FastCount would return at its option either -1 or a correct count; it could be used to pre-allocate space for a list if the size of the collection was known before it was entirely enumerated).

[Josh]

+1 For cthulhian code. Best adjective I've ever heard for bad code.

[jeroenh]

There are many other exceptions you're not supposed to catch either (StackOverflowException, OutOfMemoryException)

[Ivan]

It's also part of the core because it's useful for code generators that require you to implement something (like visual studios automatic interface implementation). Also if it accidentally gets into production, that means that you accidentally forgot to implement something, that you haven't tested against that code path and that you have a bug.

[Wayne Werner]

Sadly, I am elbow deep in Cthulhian code lately. No NotImplementedExceptions, that I know of - but I would much prefer a function that doesn't exist to one that exists only to give tentacle hugs.

[vpalmu]

The case of IDataReader and friends indicates the use. Most instances use only a subset of its methods. When constructing the interface as a wrapper, the unused stubs need to do something. This is about the most sane thing to do.

[supercat]

Worse, how about something like Point ComputeLocation() { return default(Point); }. There are many cases where the correct behavior for a method with no return value is simply do nothing (e.g. many classes implement IDisposable.Dispose() as a no-op), but having a method that returns a structure type return a default instance as though it were a real value seems really dubious.