# Thursday, August 1, 2002
« No Title | Main | No Title »
No Title

Stuart commented:

On most aspects, you've convinced me. Just a few little comments:

wrt "throws Exception" vs "throws Throwable" - there's no difference. Any Java method can throw any Throwable subclass that isn't an Exception subclass, just as any Java method can throw any RuntimeException subclass. Thus "throws Exception" really does let you throw anything.

Actually, no. Try to compile the following:

class test extends Throwable
{
  public static void main(String[] args) throws Exception
  {
    throw new test();
  }
}

It doesn't compile. One of the inellegancies of Java's checked exceptions model is that there are two classes that removed the checkedness, both Error and RuntimeException.

Btw, are you arranging that (most? any?) .NET exceptions end up as subclasses of j.l.Exception, or just direct Throwable subclasses?

Throwable, the most important reason is that I don't want to mess with the class hierarchy, if at all possible.

I agree also that remapping things like InputStream is probably too hard. If you have a generic class/interface/method remapping system, though, I can imagine actually experimenting with Collection vs IEnumerable and indexers on List.

One of the goals of XML remapping system, is to enable exactly these types of experiments. It probably isn't flexible enough to do everything you'd want to do, but in the end we'll get there.

When you get IK.VM working on Mono I might even have a try at that myself, since it shouldn't need any deep magic in the VM itself.

I think it'll still be a while before Reflection.Emit in Mono is at the level where it is complete enough.

Oh, and I like the idea of custom attributes to do "throws" expressions on glue code. I wonder if we could persuade the Mono people to get mcs to actually honor the "throws" attributes - ie, compile C# code with Java's 'checked exceptions' semantics. That would be pretty cool :)

It would be cool, but I don't really like checked exceptions. After programming in Java (almost exclusively) for about five years, I finally decided that the cons outnumber the pros. The idea is compelling, but in practice there are too many problems, but I don't really want to start that war, as it has been waged many times already ;-)

BTW, I just changed the idiv, ldiv, irem & lrem implementations to explicity check for -1, and for a lame little test I wrote, performance seems to be OK (same as JDK 1.1 and slightly faster than JDK 1.4, HotSpot doesn't like microbenchmarks ;-)).

Thursday, August 1, 2002 5:14:02 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [3]
Thursday, August 1, 2002 11:25:11 AM (W. Europe Daylight Time, UTC+02:00)

Btw, I'm just trying out your latest snapshot. I'll add further comments as I get further, but so far I had to make a couple of changes to let me build:


VS.NET treated "if (false)" on line 1732 of vm.cs as creating unreachable code. I changed it to "if (false.Equals(true))" so that it didn't treat it as a compiletime constant.


And the default compilation options disallowed unsafe code, so I had to change that in order for BigEndianBinaryReader.cs to compile.

Stuart
Thursday, August 1, 2002 11:42:16 AM (W. Europe Daylight Time, UTC+02:00)

Okay, I've got it to the point of giving me an intelligent error at runtime, at least. Issues so far:


It doesn't (seem to) honor CLASSPATH, at least when run from a command prompt. So you have to cd to the directory that contains your classes, and if they're in more than one directory or in a zip file you seem to be SOL right now. Maybe there's a classpath commandline argument, but if so it doesn't tell you so when you run it with no args. Fortunately, for what I wanted to try, all my sources are in one place.


Now the showstopper that I haven't been able to figure out how to get past. As far as I can see the download doesn't include *any* of the GNU Classpath libraries, which means that (as far as I can see) it can't run anything at all. I'm guessing that this is just a simple omission from the zip - is that right?

Stuart
Thursday, August 1, 2002 11:55:50 AM (W. Europe Daylight Time, UTC+02:00)

Oh, and wrt your comments - gah, I guess the docs I read when I first learnt Java were either lying about checked exceptions, or I misremembered them. What I remember the docs saying was that it was Exception that *added* the checkedness, and then RuntimeException that removed it.


Interestingly, my take on checked exceptions (after programming in Java for almost as long as you have) is the opposite of yours - I still feel that the omission of checked exceptions is the biggest single problem with C# and the CLR. I'm not going to get into the war either, it's just interesting that with the same length of Java experience (although yours clearly goes much *deeper* than mine if you can write a VM) we've arrived at opposite conclusions.


What would have been really nice, IMHO, would have been for C# to support some kind of *optional* checked exceptions. What I mean by that is something like this:


void foo() { ... } (C#) ==> (Java) void foo() throws Throwable { ... }


void foo() throws FooException { ... } ==> void foo() throws FooException { ... }


void foo() throws void { ... } ==> void foo() { ... }


That way, as long as they were careful about declaring exceptions on all public standard library functions, programmers who like checked exceptions could use them, and programmers who don't wouldn't have to.


If necessary, they could also add a special declaration that would turn off checking exceptions in the body of your method, so that it would be possible to call code that doesn't check exceptions, and give a meaningful throws clause, but not have to put an exception handler in to catch everything else.

Stuart
Comments are closed.