Peace For All

Let me start off by saying that the interface rocks. Use it for awhile, then go back to an application that is structured around menus, and there is this giant feeling of “What have we been doing for all these years? The entire industry is stupid!”

The interface is that good.

But Office 2007’s downfall will be the same downfall that Office XP had, and the same massive problem that Open Office has:

Slow load times.

A common use for Word is to spell check random bits of text. Click the blue W, [cntrl-v], [f7].

Under Office 2007 that procedure is now Click the blue W, [Whistle show tunes], [take a short nap], [cntrl-v], [f7]

Once any of the Office 2007 applications get started up they perform well (though Outlook has some minor performance issues) and yes there are performance gains to be had once the code base is cleaned up and readied for release, but those minor speed gains are not likely to offset the overall slow load time for what users expect to be a very simple set of applications (Write text, add numbers together, send and recieve email).

It is important for developers to remember that ultimately the users do not care how eloquent our code base is, they just care if the software delivers the desired functionality. Does eloquent code enable rapid deployment of features that the users desire? Often times yes, but if a user can load up a web app in less time than it takes to load up an eloquently programmed desktop application, well, which one do you really expect the user to use?

Load any MSDN page dealing with .NET 2.0.

Who the heck decided that it was a good idea to preload thousands upon thousands of items, before loading the article?

Oh and this is one place where frames might be a GOOD thing.  Having to load that same data each time I visit a site (IE7 and Firefox) is annoying.

I do think that IE7 has a slight speed edge, but, umm, after the first 3 seconds, who really cares?  Especially since I have to do this for each and every method in a class.

I am playing around with C#.  Win32/C# class and all that.

I am opening a Graphics file.   A dialog pops up, the user selects a file.  If the user hits OK, I construct a new Bitmap using the file.

That latter bit is copied straight from the MSDN article on the same topic.

Now I <i>now</i> that this is wrong.  All the user has to do is select an invalid file type and exceptions will get thrown all to heck.  They won't be CRITICAL exceptions mind you, not for this simple application, but the application will keep on functioning, assuming that a valid file has been opened.

This is stupid.  Why the hell can't the compiler say "Hey, Devlin, by the way, that constructor there can throw an exception."

I know it can.  Do I want to go and dig through MSDN finding the exact exception name?  Not really.  For whatever reason, IntelliSense is not popping up a list of exceptions that can be thrown by the Bitmap constructor.

What do i want to happen?  I want to hit a hot key, have basic exception handling code thrown up for me, and then go in there and customize the handling.

Yah, sure, I just turned in 30 pages of Java code for class on Friday, and yah, sure, I would estimate that about 8 to 10 pages of that (at least!) is exception handling.  This is because I went about and handled my exceptions <i>properly</i> (informing the user which of their actions is causing a problem and how to remedy the problem, for instance), and got some good information pushed out for myself, the developer, as well at the same time.

And yes, a lot fo that execption handling code is for situations that I <i>personally</i> know will never happen.  Invalid IO exceptions in case arguments passed into a constructor are invalid, in cases where I had just created the object that was being passed in, so I <i>knew</i> that it was valid.

Yah well, I still feel more comfortable handling <b>extra</b> exceptions than not handling <b>enough</b> exceptions.  Requiring the programmer to explicitly break their stride and go in too add every single exception that could happen is just ludicrius.  Especially when the IDE can do it for me!

I am sure that there is some button in Visual Studio to do exactly this, but why shouldn't the compiler bug me if I haven't hit it yet?  Worst case worst, I hit compile and ship the software out the door, and <i>it breaks with ease</i>

The cost benefit trade off of checked exceptions is minimal.  Visual annoyance in return for more stable code.

Finally, I must say this.  It requires discipline to properly catch checked exceptions.  But I believe that it requires even more discipline to catch unchecked exceptions.