On Sun, Mar 30, 2003 at 07:08:54PM +0200, Stefan Matthias Aust wrote: > Basically you say, add "throws" only to public methods as these are > probably the interface methods other users might care about and where > they should and their compilers know about about possible exceptions.
It's not because "these are probably the interface methods other users might care about". I add throws only to public methods because I'm trying to annotate the minimum set of methods and still have checked exceptions. I admit there are some tricky issues with protected methods in subclasses, but no first draft proposal is perfect. > Let's say you want to create an iterator that implements the > java.util.Iterator interface class. Let's say that itertor should > iterate some database stuff. Every database operator might throw an SQL > exception (a checked exception). But the Iterator interface doesn't > allow you to throw exceptions, as potential users of iterators might not > deal with them. So you have to wrap your checked exceptions with > uncheckt runtime exceptions, working around the too strict default > mechanism. That's annoying. That's a really good example. My problems with checked exceptions mostly have to do with them getting in my way for a temporary period of time while I'm starting development on some new code. Your example is actually a case where checked exceptions break language behavior. I'll add that issue to my proposal. > I wouldn't mind if I don't have to add declarations to non-public > methods though. Ahh, so you see the point now. :) > However, as especially protected methods are meant to be overwritten > by other users in their subclasses, these methods might also need a > throws declaration. This certainly is an interesting case to handle. I'll add it to my proposal. > I agree with you, that the whole matter could need some thought. Do > you know Bruce Eckel's position paper on not using checked > exceptions already? Yes, of course. However, I don't agree with him. I agree that Java's "thorough checked exceptions" system is overkill and annoying. However, I find throws declarations in public class methods to be extremely helpful when writing Java code. I just find it annoying to have to add declarations for my code when the compiler could do a fine job. Inferring thrown exceptions is not hard like ML-style type inference -- It's trivial. > [snip...] higher performacne isn't something I really care about. Then I won't bother with any of the performance conversation. Obviously it's important to me. It's also important to a few other people I'm sure. > > C# is faster at (a) and (b) by using C++ style static vtable lookups > > for methods. "really fancy" Smalltalk runtimes like the SELF/Smalltalk > > runtime which eventually became hotspot can sometimes optimize out > > this overhead at runtime if a single type appears in the > > hashtable. > > What you call "really fancy" is actually the norm - not considering > simple interpreter like Squeak or Dolphin Smalltalk. The SELF runtime basically invented polymorphic inline caches. Their Smalltalk->SELF emulation environment for Smalltalk was about 4x faster than Digitalk Smalltalk (from memory). It also took a buttload of memory. Sun's Java Hotspot VM was one of the first commercial runtimes to include polymorphic inline caches. If you have a documented reference to a non-SELF, non-Hotspot VM which does this, I'd like to see it. > Intel's research implemententation uses PICs. Do you have a documented reference you can point me to? AFAIK, non-Hotspot runtimes are limited to simple inlining, they don't really do type-specific, multi-method call "polymorphic inline caches" like SELF does. I've talked with David Ungar about some of the challenges converting SELF's PICs into Hotspot, and it really wasn't a no-brainer. It also isn't a clear win, as Java VMs without it do better in some cases. > Another problem with simple vtables occur with interfaces The C++ multiple inheritence vtable dispatch mechanism is pretty damn fast compared to Java/Smalltalk/Objective-C style dispatch. It's perfectly capable of doing Interfaces. Obviously enough inlining (aside from memory usage, complexity, and compiler pauses) can optimize all of these into something simpler. > Actually, using inlining the SELF way, you'd get the same advantage > without generics and everywhere, not only in collections. Some help > form the user can however of course simplify and speed up the JIT > compiler. I've run the SELF environment and written SELF code and IMO, we are a LONG way from SELF being anywhere near the performance of Java or C#, even with all that fancy stuff, let alone C++. All that stuff is interesting in theory, but the system really took tons of memory and still wasn't fast. The SELF VM was amazing because it took a totally impractical message passing meta-language and made it faster than then-current Smalltalk runtimes. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [EMAIL PROTECTED] _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
