From: Peter G. <pe...@ar...> - 2005-10-27 12:27:59
|
On Wed, 26 Oct 2005 at 18:47:48 +0200, Andras Simon wrote: > On Wed, 26 Oct 2005, Peter Graves wrote: > > > > Consider an application that uses multiple third-party library modules. > > One module might do > > > > (define-condition null-pointer-error (java-exception) ()) > > (register-java-exception "java.lang.IllegalArgumentException" > > 'null-pointer-error) > > > > and another module might do > > > > (define-condition null-pointer-exception (java-exception) ()) > > (register-java-exception "java.lang.IllegalArgumentException" > > 'null-pointer-exception) > > > > It seems like whichever of these modules is loaded last will get its > > way with the handling of NullPointerExceptions, and the other one won't > > see them at all. This is what I was getting at when I complained that > > global mappings don't give you granularity. > > > > What should we do about this? > > Perhaps we could avoid it by having > > (def-java-exception "java.lang.IllegalArgumentException") > > as opposed to > > (def-java-exception illegal-argument "java.lang.IllegalArgumentException") > > i.e. by not letting the user mess with exceptions too much. This seems > like a relatively clean if not very flexible approach. Yeah, this is essentially the jFli approach, applied to the subject of exceptions. I think this approach is fine, but it's a higher level approach, and should be part of the higher level API, which is not really what we're talking about here. > Or we could signal a continuable error in case of a redefinition (or > should I say re-registration?) attempt. (I like this the best.) OK. > There could also be a rebinding mechanism (as with dynamic variables) > but that somehow feels wrong (and an overkill) to me. Not that I see > clearly what this would involve. I don't really see what this would involve either, and it does seem like overkill, so let's not go down that road. > The longer I look at it, the more I like the second option. I think that's a fine plan (the second option being a continuable error in case of a re-registration attempt, just to be perfectly clear). > Especially, for a 0.1 release. We just don't have enough experience to > know if it'll hurt anyone, so why draw up elaborate plans to avoid the > pain that may never come. And option no. 2 also leaves room for some > experimentation. > > Motto: People should be creative in how they deal with errors, not how > they name it. > > What do you think? I think there's at least one further issue. Suppose (for the sake of argument) you do: (define-condition throwable (java-exception) ()) (register-java-exception "java.lang.Throwable" 'throwable) And then some call to Java throws a NullPointerException (for example). Now, you haven't registered "java.lang.NullPointerException". But from Java's point of view, a NullPointerException _is_ a Throwable, so the condition registered for "java.lang.Throwable" should arguably be signalled. You can't accomplish this with a simple hashtable lookup of "java.lang.NullPointerException". You'd have to walk the list of registered exceptions and check to see if the class of the exception at hand is either identical to, or a subclass of, one of the registered exception classes. And the order in which you walked the list would matter, in exactly the same way the order of catch clauses matters after a try block in Java code. Having mentioned this issue, I don't plan to do anything about it right now. For the moment, I think I'm going to leave the registration mechanism as it is, except that I do plan to introduce a JavaException class, more or less as we've discussed it, and make sure that when no exceptions are registered, Java exceptions are caught and a well-formed JavaException (or JAVA-EXCEPTION) is signalled on the Lisp side, with a plausible error message. This should be reasonably safe, while leaving plenty of room for experimentation while we acquire the experience that will enable us to do a better job somewhere down the road, when we have real users complaining about real problems. Thanks for your help with this! -Peter |