When extending a base class with abstract methods, the new class must implement all the abstract methods of the base class. Integrated Debugging Environments (IDEs) such as Eclipse can easily add stubs for the abstracts methods, which will be marked with a "TODO" comment. While I was importing some code from 2003, to fix this error Eclipse inserted dozens of these stub methods in the class. The code was creating a RestrictedResultSet by extending ResultSet. Apparently the ResultSet object has been expanded since this code was originally written.
I started thinking about what to do when I am using this class. I am not going to take the time to implement all these extra stubs. How do I avoid using these extra stub routines?
My first idea was to make a new exception class to implement an "UnimplementedException". This would cause Eclipse to want to add a try/catch around every use of an unimplemented routine, thus helping me catch the problem at edit/compile time, rather than at runtime:
Unfortunately, changing this
to this
doesn't work. This gets the error
"Exception UnimplementedException is not compatible with throws clause in ResultSet.getURL(int)"
The methods in this class that implement abstract methods from the base class must have the same signature. Changing the throws clause changes the signature.
So it looks like there is not an easy way to add a new exception to a descendant class.
I was able to find a different way to do this that will at least throw an exception at runtime:
I got this idea from Per Bothner's complaint
 | From: Per Bothner <per at bothner dot com> To: java at gcc dot gnu dot org, classpath at gnu dot org Date: Sat, 01 Mar 2003 16:02:25 -0800 Subject: unimplemented methods I just looked at a couple of classes (java.net.URI and java.awt.GridBagLayout) and noticed lots of unimplemented methods just do nothing or return null. This has to stop. If an method does not do what it is supposed to do, then it must throw an exception. I'll make an exception for a method where you might get semi-useful results if it isn't implemented correctly, but if a class isn't anywhere close to useful, it shouldn't pretend to be. That raises the question: What exception to throw? We could add a special gnu exception, but I suggest UnsupportedOperationException. E.g: |
It's amazing that this comment was from about the same time period as the library code I picked up to use. Too bad that IDE like Eclipse don't add this throw to the stubs they generate.
Searches:
- java unimplemented method exception
- java exception is not compatible with throws clause
- java throws multiple exceptions
- java constructor call must be the first statement in a constructor - ran into this with the first version of the constructor I copied from some student's question. In this case, Super was in fact the first statement, but after looking at it for a while I realized a return type had been put on the constructor, and it was causing this error. Don't make a constructor return void!
Hey guys having a little trouble doing an assignment of mine that's dealing with Unimplemented methods. ....
Assignment
1) Create a class UnimplementedMethodException as a subclass of Runtime exception. Have the constructor take two arguments a Class class and a String methodName. Create a message“Method “ + methodName +
“ not implemented for class “ +class.getName()Pass it to the super class constructor.
Define UnimplementedMethodException in package edu.iup.cosc210.util.
Someone answered it if extendend Exception, it would be good to actually extend it:
public class UnimplementedMethodException extends Exception....
But that missed several other errors, such as cls instead of class, getName being a method and not a field, etc.
- java unimplemented exception