As if MSBlaster wasn't enough... Tonight I started getting e-mails from the .NET Messenger Service staff, about the required upgrade for MSN Messenger and Windows Messenger. No problem there, although I do update my XP box regularly. Unfortunately for Microsoft, I've received 7 identical copies of this message since 7:14PM. Ironically (and I hope not chronically), an action that is part of the Trustworthy Computing Initiative is actually decreasing my level of trust and confidence.

Mark Baker takes Adam Bosworth to task for not understanding the web. Or more properly, for not thinking RESTian thoughts. I've done a little bit with REST, and quite a bit more with SOAP/WSDL, and at a certain level of abstraction it doesn't matter whether the glue between the client and the web is REST or web services. Of course, at another level it's vitally important, but that's what the REST and web services disputes are all about. The web services folks are advancing their vision (soon, they'll need an acronym demystifier), and the REST folks are claiming that we already have all that we need.

Look at what Mark spent a lot of effort on:

I spent a good amount of time trying to figure out how to integrate CORBA, OpenDoc, and the Web, in an attempt to yield what Adam's asking for.

Cross off CORBA and replace it with either REST or web services. The Web is already there. The missing piece is OpenDoc or something like it. Browsers are all well and good, but we need to integrate the data with what's on the local machine (at least until we've turned PC's back into 3270's speaking HTTP). Browsers don't do that very well. The big piece that we need to make progress on is something like what OpenDoc was. Java doesn't have something. Microsoft stopped working on theirs after OpenDoc disappeared into Area 51 along with CommonPoint and Dylan. The only memorable things about Longhorn are a UI that needs DirectX 10, and a database layer that sits on top of NTFS. The Gnome guys were working on Bonobo, but the last time I was with Miguel he was apologizing to someone about Bonobo, so that's not encouraging.

• You know we're in trouble when we need an XML Acronym Demystifier. Things are really getting out of hand.

• Tim Bray is extolling RelaxNG after his experiences writing a schema for Pie/Echo/Atom/Whatever. I agree that RelaxNG is technically superior to XML Schema. I've all but given up on RelaxNG supplanting XML Schema as the majority schema language for XML. I suppose that's mostly because I'm looking at it through the lens of Xerces and the disinterest we've had from RelaxNG knowledgeable folks in the past.

  Something needs to happen for RelaxNG to pick up momentum. Right now, it's just another one of those acronyms that we need the demystifier for. Until the RelaxNG community starts showing up to projects and helping to build RelaxNG support, RelaxNG will remain obscure. A few years ago I tried to use the leverage that we had with Xerces-J to try and advance RelaxNG, but no one was interested enough to help us. If the RelaxNG folks don't care enough to get RelaxNG support into the most popular processors in all the major languages, then they can't expect the rest of us to care.

• I partially disagree with Aaron Swartz and Mark Pilgrim (and probably a host of others) on Postel's law. All the examples that Aaron gives are related to documents that users might process (this includes RSS feeds, where I've been bitten by his reason #1). I agree that in those situations, it's desirable for the parser to be Postel compliant (i.e. lenient). But in situations where the XML is generated for machines, by machines, I think that the XML spec writers were correct. Let them eat fatalErrors, because there's a bug in a program somewhere that needs to get fixed.

  One of the motivations for the Xerces Native Interface was to allow us to build families of parsers by replacing pieces of the framework. So you could implement a strict XML parser (which is what XMLDocumentScannerImpl is) or you could implement a Postel XML parser. Only problem is that nobody cares enough to implement a Postel XML parser.

Bill Venners and Bruce Eckel interviewed Anders Hjelsberg on the topic of checked exceptions. My contention has long been that checked exceptions are a good thing, but that the way that they've been used in the Java API's is a disaster. These two quotes support that idea.

Frankly, they look really great up front, and there's nothing wrong with the idea. I completely agree that checked exceptions are a wonderful feature. It's just that particular implementations can be problematic. By implementing checked exceptions the way it's done in Java, for example, I think you just take one set of problems and trade them for another set of problems. In the end it's not clear to me that you actually make life any easier.

Checked exceptions are good.

You see programmers picking up new APIs that have all these throws clauses, and then you see how convoluted their code gets, and you realize the checked exceptions aren't helping them any. It is sort of these dictatorial API designers telling you how to do your exception handling. They should not be doing that.

API designers are using them wrongly.

So far, no disagreement.

The Hjelsberg brings up two areas that I haven't seen discussed before (or at least not from this point of view): the impact of checked exceptions on versioning of classes/interfaces, and the issue of scalablity. The scalability one is particularly convincing for me.

The scalability issue is somewhat related to the versionability issue. In the small, checked exceptions are very enticing. With a little example, you can show that you've actually checked that you caught the FileNotFoundException, and isn't that great? Well, that's fine when you're just calling one API. The trouble begins when you start building big systems where you're talking to four or five different subsystems. Each subsystem throws four to ten exceptions. Now, each time you walk up the ladder of aggregation, you have this exponential hierarchy below you of exceptions you have to deal with. You end up having to declare 40 exceptions that you might throw. And once you aggregate that with another subsystem you've got 80 exceptions in your throws clause. It just balloons out of control.

Even if API designers use checked exceptions correctly, the blow up certainly causes problems. But what's the solution here? I like the idea of checked exceptions, but this inability to scale is evident in large Java programs.

C# is basically silent on the checked exceptions issue. Once a better solution is known-and trust me we continue to think about it-we can go back and actually put something in place. I'm a strong believer that if you don't have anything right to say, or anything that moves the art forward, then you'd better just be completely silent and neutral, as opposed to trying to lay out a framework.

This seems like wisdom to me. Study the problem some more, get some more practical experience and then add a truly useful feature. I can respect that.

And so, when you take all of these issues, to me it just seems more thinking is needed before we put some kind of checked exceptions mechanism in place for C#. But that said, there's certainly tremendous value in knowing what exceptions can get thrown, and having some sort of tool that checks. I don't think we can construct hard and fast rules down to, it is either a compiler error or not. But I think we can certainly do a lot with analysis tools that detect suspicious code, including uncaught exceptions, and points out those potential holes to you.

This is a variant of what I've been saying regarding the static vs dynamic typing issue. Maybe it really does make sense to keep some features like static types and checked exceptions out of the language, and provide better analysis tools that can be run over the code. If these tools became part of the programming environment, then their warnings would be indistinguishable from compiler errors or warnings.