[Mono-list] limited checked exceptions proposal discussion

[David Jeske]

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/ + jeske@chat.net