On 3/20/06, Andrew John Hughes <A.Hughes@xxxxxxxxxxxxxx> wrote: > It sounds like a bad hack on the JAPI side, but it's up to you if you're > maintaining this. True enough, but I think the problem of stub-inflated japi reports is important enough to try to find some way of tackling it. Obviously an annotation would be nicer and I'll probably migrate to that once it becomes practical, but I'd rather have a hacky solution today than no solution at all for months. > I can't currently find NotImplementedException in > Classpath outside the new jdwp code, but I may be missing something. > If we have a gnu.classpath.NotImplementedException, then we could catch > this specifically in JAPI, and also output a nice message. I must have misremembered I guess. Japi actually scans for *anything* called "NotImplementedException" in any package (because I was writing this code while offline and besides I want it to work for other projects too who might not be happy with "gnu.classpath." (coughharmonycough). > The immediate problem I see (and why we don't generally use an exception) is > that the problem can still continue with an exception, whereas it can't with > an error. I could easily change it to "NotImplementedError", or accept either. The important thing from Japi's perspective isn't whether the exception *actually* gets thrown - it could be, or the class could silently do nothing as it currently does, which in some cases may still be preferable if the functionality is noncritical. All Japi cares about is whether it shows up in the throws clause. > The main problem I can foresee is actually finding all the code and putting > this in... Yep. Hence the question about automated scanning to find a list of candidates... :) I'd rather have a process that gives lots of false positives than a process that misses lots... Stuart. -- http://sab39.dev.netreach.com/
