Anders Hejlsberg

In a recent interview Anders said:

If you ask beginning programmers to write a calendar control, they often think to themselves, "Oh, I'm going to write the world's best calendar control! It's going to be polymorphic with respect to the kind of calendar. It will have displayers, and mungers, and this, that, and the other." They need to ship a calendar application in two months. They put all this infrastructure into place in the control, and then spend two days writing a crappy calendar application on top of it. They'll think, "In the next version of the application, I'm going to do so much more."

Once they start thinking about how they're actually going to implement all of these other concretizations of their abstract design, however, it turns out that their design is completely wrong. And now they've painted themself into a corner, and they have to throw the whole thing out. I have seen that over and over. I'm a strong believer in being minimalistic. Unless you actually are going to solve the general problem, don't try and put in place a framework for solving a specific one, because you don't know what that framework should look like. [Artima's interview with Anders]

I like Anders' position regarding Checked Exceptions, contrast this with James Gosling's statement, which I believe does paint a broken picture:

One of the traditional things to screw up in C code is opening a data file to read. It's semi-traditional in the C world to not check the return code, because you just know the file is there, right? So you just open the file and you read it. But someday months from now when your program is in deployment, some system administrator reconfigures files, and the file ends up in the wrong place. Your program goes to open the file. It's not there, and the open call returns you an error code that you never check. You take this file descriptor and slap it into your file descriptor variable. The value happens to be -1, which isn't very useful as a file descriptor, but it's still an integer, right? So you're still happily calling reads. And as far as you can tell, the world is all rosy, except the data just isn't there. [Artima's interview with James Gosling]

This is in fact the source of many security problems. One of the first security code audits I witnessed was by a volunteer that reviewed my first setuid application that I shipped as part of the Midnight Commander (the software only shipped after the security audit). A 200 line program got back 700 lines worth of comments, many of them related to not checking error conditions from trivial system calls like `close()'.

But modern C APIs do not use int return codes, in fact not even the C standard library uses those: that is only the low-level Unix C API that has this feature. The standard C library API returns a FILE * object, and for instance, most of Gtk+ and Gnome APIs return objects (in the form of a pointer to an object).

The beauty of returning a pointer to an object, is that you can return NULL as your standard error return value, and if the value mattered, you will most likely take the necessary steps to check its return value, or they application will just crash the moment you try to use it.

This could be applied to the .NET and Java APIs to reduce the amount of required try/catchs. For example, the File.IO.OpenRead method could be (shown here is the artist's representation):

	public static FileStream OpenRead (string file)
	{
		int fd = open (file);
		
		if (f == -1)
			return null;
		return new FileStreamFromFD (f);
	}

Which makes null a valid return value. If you fail to check for the return value, you would get a nice NullReferenceException, but you would allow the expensive creation of an exception object, and the ugly try/catch block in the call site.

Obviously we can not change the existing APIs, but we could encourage developers to minimize their use of exceptions. In my limited personal experience with software design, when I have faced applications with tons of Exceptions it was extremely hard to keep up with them. A rewrite of the software to avoid exceptions and use the more sane API paid for.

More Mono Bloggers

I wrote about Ben previously, he now has a blog which we are hosting for him at Ximian.