Is there anything like .NET's NotImplementedException in Java?
Is there anything like .NET's NotImplementedException
in Java?
Solution 1:
Commons Lang has it. Or you could throw an UnsupportedOperationException
.
Solution 2:
I think the java.lang.UnsupportedOperationException
is what you are looking for.
Solution 3:
You could do it yourself (thats what I did) - in order to not be bothered with exception handling, you simply extend the RuntimeException, your class could look something like this:
public class NotImplementedException extends RuntimeException {
private static final long serialVersionUID = 1L;
public NotImplementedException(){}
}
You could extend it to take a message - but if you use the method as I do (that is, as a reminder, that there is still something to be implemented), then usually there is no need for additional messages.
I dare say, that I only use this method, while I am in the process of developing a system, makes it easier for me to not lose track of which methods are still not implemented properly :)
Solution 4:
As mentioned, the JDK does not have a close match. However, my team occasionally has a use for such an exception as well. We could have gone with UnsupportedOperationException
as suggested by other answers, but we prefer a custom exception class in our base library that has deprecated constructors:
public class NotYetImplementedException extends RuntimeException
{
/**
* @deprecated Deprecated to remind you to implement the corresponding code
* before releasing the software.
*/
@Deprecated
public NotYetImplementedException()
{
}
/**
* @deprecated Deprecated to remind you to implement the corresponding code
* before releasing the software.
*/
@Deprecated
public NotYetImplementedException(String message)
{
super(message);
}
}
This approach has the following benefits:
- When readers see
NotYetImplementedException
, they know that an implementation was planned and was either forgotten or is still in progress, whereasUnsupportedOperationException
says (in line with collection contracts) that something will never be implemented. That's why we have the word "yet" in the class name. Also, an IDE can easily list the call sites. - With the deprecation warning at each call site, your IDE and static code analysis tool can remind you where you still have to implement something. (This use of deprecation may feel wrong to some, but in fact deprecation is not limited to announcing removal.)
- The constructors are deprecated, not the class. This way, you only get a deprecation warning inside the method that needs implementing, not at the
import
line (JDK 9 fixed this, though).