Both C++ and Java (and other programming languages as well) support a notion of exception specifications. The design and even the desirability of these specifications is controversial. In C++, for example, the exception specifications are enforced at run time; if a function throws an unexpected exception the running program is (by default) aborted. In Java the exception specifications are enforced statically. If a method tries to throw an unexpected exception the program won’t compile. Which approach is better?
Exceptions are a dynamic process. The precise exceptions thrown by a program and where they are handled depend on the inputs given to it and on the execution path taken by the program as it runs. One might reasonably wonder if all possible exceptions that a program might throw are handled somewhere. Can this even be determined statically? My guess is that the question is undecidable in the general case. I don’t have a proof of this, but I’d be surprised if it was otherwise. Thus any static analysis must necessarily be either unsound or incomplete or both. In the case of exception specifications this means that either the analysis misses some exceptions that might be thrown and thus says all exceptions are handled when they are not (unsound), or the analysis forces the programmer to handle exceptions that in fact can never be thrown (incomplete).
Many exceptions have the potential to arise very often. For example in Java the null pointer dereferencing exception could potentially arise whenever an object or array is accessed. Requiring this exception to be part of an exception specification would essentially mean that every method would need to be decorated with that exception (and then what would that really tell you?). To avoid this Java’s exception specifications are unsound; certain exceptions, the so called “unchecked” exceptions, do not need to be covered by exception specifications. However, this means that the static analysis done by the compiler doesn’t really answer the question you’d like answered: are all possible exceptions handled in some way? Yet despite that, Java’s handling of exception specifications is also incomplete; among checked exceptions it is still possible that the compiler will force you to handle an exception that, under your specific conditions, can’t occur.
C++ checks exceptions specifications dynamically. This has the advantage of being precise; only those exceptions that actually do violate the specifications are reported. However, this leaves open the problem of what should be done when such a violation is detected. The program is already running at that point so the way in which this error should best be handled is likely to be application specific. Aborting the program outright might be reasonable in some cases, but probably not in most cases. C++ allows the programmer to translate unexpected exceptions into expected ones (using unexpected handlers) but this has the disadvantage of throwing away information about the original exception (although one could imagine an unexpected handler that logs the original exception in some way before translating it).
Yet there are issues with exception specifications that transend the static vs dynamic question. For example an exception thrown in a call back function that propagates through a third party module and is eventually handled by the client of that module should be perfectly well behaved. Yet the exception specifications in the third party module can’t possibly know about the client’s exceptions. There are also questions regarding the handling of exception specifications in generics or templates, etc. Many issues with exception specifications have been described with proponents on both sides of every argument. One is left with the distinct impression that the community just doesn’t know right now how to best handle exception specifications.
To summarize, static checking of exception specifications is unsound and dynamic checking leaves open the problem of how to handle violations. For these reasons, along with other questions about them, I suggest that exception specifications, as we currently understand them, are a bad idea. I am glad that Ada, my favorite language, does not have them. I would encourage the Ada community to be very careful about incorporating them into a future version of the language. I’m not saying that exception specifications can’t be defined in a reasonable and useful way. I’m only saying that doing so is trickier than it at first appears and that neither Java nor C++ got it right.
Not long ago the Visual Studio installation on my main laptop decided to not work. Specifically, as soon as I opened any project Visual Studio closed immediately without any messages of any kind. The problem turned out to be related to the VMware plug-in for Visual Studio.
Any heavy computer user is going to encounter issues like this from time to time. That’s just life in this field. Still, when it happens to me I tend to get philosophical. I wonder if computer systems have become too complicated for their own good. Certainly I personally do not need all of the features and capibilities that modern software packages provide. I didn’t even know VMware had a Visual Studio plug-in until it started acting up on me. When complex software packages begin to misbehave because of interactions between components I don’t care about… something has to be done. But what?
I long for the days of simple software. I want software that only does what I need and not one thing more. Of course when I need my software to do something new, I’d like that new feature to become available. How could that happen? There is only one way I can see to get software like that: write it myself.
Thus I introduce “Project Wheel.” The goal of Project Wheel is to build a system composed entirely of software I wrote myself. Such a system would be small and simple (out of necessity), and also extremely customized to suite my needs. In addition I would, in theory, understand how it all works… and be in a position to personally fix anything that is broken.
Of course this idea is utterly nuts. Even if I worked 24/7 for the rest of my life I would not be able to single handedly buid a usable system from scratch. Yet even if the goal is unattainable the philosophy is, perhaps, still worthwhile. It is a philosophy of simplicity and self-reliance. Software should be functional, to the point, and tailored to the individual… not loaded with useless glitz that might (or might not) be interesting to someone somewhere.
Yet if Wheel is to have any practical feasibility at all, some concessions will be necessary. For example, I think one reasonable compromise would be to use software built by a team of which you are a member. Thus a follower of Wheel could use traditional open source packages provided he or she is actively participating in the development of those packages.
For example, I’m involved in the development of Open Watcom. Thus I could be fairly true to the Wheel philosophy if I used Open Watcom as the compiler for all my programs. It’s true that I don’t understand how all of Open Watcom works. However, I could in principle come to understand it because it is open source and, what’s more, I’m already engaged with that project and working on it.
Obviously it isn’t feasible to build an entire, modern system from custom made software. Yet I wonder how far one can really go with this idea. Years ago I wrote a simple text editor of my own. Maybe it’s time to clean up that source, compile it with Open Watcom, and then use it to start cranking out software. Yes, maybe it’s time to reinvent the wheel.
I’ve had this blog for about eight months and yet I’ve only posted a few entries in it. Honestly I don’t have all that much to say, and I don’t want to talk just to hear myself talk. Instead of spending time maintaining this blog I find that I’d rather spend time working on one of my many projects. So I’m officially putting this blog on indefinite hold. I may return to it someday when I have in mind a clearer purpose for it. I may never return.
The point of blogging has always been unclear to me. I can see the value of it as a way to support or promote an open source project (for example). Such blogs are well focused and often contain interesting and useful information for the users of the project. However, a blog that is nothing more than technically rambling does seem rather useless.
It is common to find single applications that integrate several services that could have sensibly been provided with separate applications instead. How much integration is smart is, of course, a matter of opinion. I think integration makes sense if the things being integrated are closely related and can reasonably share application features. For example, Thunderbird supports both email and NNTP newsgroup access. This makes sense because both mail and newsgroups serve a similar purpose. Also both systems can benefit from a unified address book and common message folders. In addition, both systems support similar kinds of message content.
What about instant messaging? Many people today use IM as a major form of interpersonal communication. In some communities it is replacing email as the communication method of choice. IM systems such as Jabber even support asychronous messages; the recipient of a message need not be logged in at the time the message is sent. One can easily see the sense in using an IM sytem for informal conversation and traditional email only for longer, more formal, and more complex documents.
Given this observation, does it make sense to build an integerated email+IM client? Again both systems could benefit from a unified handling of contacts, and it might be nice to store chat session logs in folders alongside email messages. Indeed, Google appears to be headed in this very direction with Gmail and Google Talk. However, I do not know of any desktop email+IM application. Is there one? Should there be one?
I have a thing for editors it seems. Over the years I’ve used quite a variety of different ones. I’ve even written an editor of my own. As I mentioned in an earlier post, I’ve recently taken to using jEdit for my day to day editing needs. However any editor as powerful as jEdit is also a bit heavy for some applications. It’s nice to have an editor on hand that installs easily, loads quickly, and yet is still powerful enough for “real” editing when necessary. One such editor is Notepad++.
Notepad++ has become a popular tool among students at Vermont Technical College where I teach. Students like it because it is easy to use and yet modern enough to be a comfortable editing environment for programming assignments, web pages, and most anything else. Indeed, Notepad++ is surprisingly feature rich for such a small download. It supports syntax highlighting for a wide collection of programming languages, macros, various Unicode encodings, and even a plug-in architecture with a significant number of plug-ins available on the Notepad++ site. The fact that it is open source is an added bonus.
I tend to use Notepad++ when I want to take a quick look at an arbitrary text file, treating the program as a kind of file viewer with editing features. It loads faster than jEdit so it is a good choice for quick and dirty editing when jEdit isn’t already running. Also since Notepad++ is installed on all the lab machines at Vermont Technical College I know I can use it anywhere in our labs without complication. Many of my students use Notepad++ for all their editing needs.
If you are looking for a small, light editor that is also worth using, consider Notepad++.
I am a long time Emacs user. Yet although I’m comfortable with the editor, I have never really achieved “power user” status with it. I dabbled with some macros and I fiddled around with my .emacs file, but I never got around to creating any non-trivial code to extend the editor in a useful way. Also as much as I respect Emacs, I’ve grown somewhat tired of its old fashion and rather quirky interface. Thus I started looking around for a more modern editor that, like Emacs, would be powerful, extensible, and free.
I found jEdit.
I like the fact that jEdit is cross platform. I use both Windows and Linux systems extensively and, like Emacs, I can run jEdit quite nicely in both of those environments. I also like the fact that jEdit can be extended with Java plug-ins and Beanshell macros. jEdit has plenty of features, particularly with the help of a rich collection of third party plug-ins, and it sports a much more modern interface than, well… Emacs.
My only complaints about jEdit are: 1) The interface is ugly, and 2) The quality of the third party plug-ins is quite variable. Some of the available plug-ins are very nice and work wonderfully. Some are rather rinky dink. Thus one’s experience of using jEdit depends heavily on which plug-ins are involved.
Overall, however, I find myself liking jEdit more all the time. Lately I keep jEdit running constantly on my desktop and use it for all my text editing needs. In the past I ran Emacs that way, but lately Emacs has been relegated to occasional, specialized use. Now I feel like I’m ready to take jEdit to the next level and begin creating some macros and plug-ins for the complex editing tasks that I had always planned to do with Emacs some day.
Is jEdit a worthy replacement for Emacs? Maybe so.