Hi Stephan, >> what do people think about introducing a >> css.lang.NotImplementedException, derived from RuntimeException, to be >> thrown in methods which, well, are not implemented, yet? > > Why not just do implement the method instead?
(I had very little hope only it would not be *this* question you were going to ask first, but I wanted to try ... ;) Because in a finite amount of time, I can only implement a finite amount of methods ... In the process of creating a non-trivial implementation, there will be a point in time where you have a only certain percentage (<100) of your methods implemented. Nonetheless, you might want to start using this class, in particular, you might want to start writing test cases for it (which in extreme might happen when the mentioned percentage is 0). At this point in time, you will want to deal with the unimplemented method in a way that the caller (your test, for instance) notices that the method, well, is not implemented yet. In NetBeans, this is mimiced (when you ask NetBeans to create a body for all missing abstract methods) by throwing a UnsupportedOperationException with the message "Not yet implemented". So, as your implementation evolves, you can replace those with real implementations. I just like this, and want to have something similar for my C++ components :) Of course, in a release product, ideally there would be no code throwing NotImplementedException anymore ... and because of the potential difference between theory and practice, this is a RuntimeException. Ciao Frank -- - Frank Schönheit, Software Engineer [email protected] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
