Edited after Cyrus' comment on the using statement. My point was that dealing with these cases correctly is difficult to a degree that the language and platform developers can get tripped up by this stuff.
I’m a fan of Joel Spolsky and he just posted an article on a couple of subjects, Hungarian notation and exceptions.
Making Wrong Code Look Wrong
It is one of the best descriptions of the good and bad points of Hungarian notation that I have read. I’ve never used full Systems level Hungarian notation, but I used the heck out of a basic form of it whenever I had to program in VBScript since there wasn’t any other way to tell what type you had at any given time.
I’m in violent agreement with the point of the article, and it is a specific case of a general principle. Always make it easier to do the right thing. This is the goal every process should strive to reach. It doesn’t matter if it is the mise en place principle in cooking, or making sure that all your tools are easy to find and entice you to put them back in the right place, things will always go better if you have as many things that you need in front of you, and the absolute minimum to get in the way.
There are some things I disagree with in Joel’s article. Exceptions being one of them. The thing that I really like about exceptions is that they make it easy to do the right thing. An exception is for when something has gone really wrong and the right thing to do is to drop everything else and fix it right now, or just drop everything and let it all go to hell. Return values just don’t do that. It’s easier to ignore them completely and let data get all messed up (I would say corrupted, but I can’t stand the phrase corruped data anymore), and that is what regularly happened in many older applications, which is why exceptions have become so popular these days.
Exceptions have one other property that I think is driving Joel’s dislike for them. You can’t just use them a little. Exceptions force you to code like every function and every statement can throw an exception period. Adopting exceptions is like moving over to multi-threaded programming, you have to distrust everything all the time. You even have to worry if something throws between creating a new object and assigning it to a variable, and even the current C# using statement can leave things open for potential leaks. The assignment statement can be just as tricky with double locking in thread safe code. You have to worry about the compiler optimising pointer copies. Things sure are more complicated then when you could just write some C code, check some return values and keep on going. Now, even though your app might be a simple single threaded application running in it’s own safe little memory space, it’s running on a multi-threaded operating system dealing with virtual memory, and cuddling up to 12 other applications think they are safe running in their own little world.
To paraphrase Joel, this is going to be one heck of a leaky abstraction. Even though you don’t use exceptions or threads in your application, all the complexity of the operating system is going to leak in and remind you of it in some pretty nasty ways. Even though you don’t use C++ exceptions, windows has it’s own form of exceptions, and every memory access can potentially generate these. So even if you want to avoid exceptions and threads, these days you just can’t.
Joel mentions a few levels of development knowledge in his article, from a complete novice, to someone that recognises code formatting issues, to someone that cares about things like making wrong code look wrong. I think there is another area, someone that has seen enough things go wrong, in there code that a pessimistic view like exception handling looks good. While I haven’t seen errors like xor eax,eax fail, I have seen many many strange things happen to my code. For 5 years I worked on Dell’s support site. While I worked there it would routinely get around a million plus page requests a day, so at least one once in a million events happened in our code a day. In fact I think the best day error wise we had while I was there was somewhere in the thousands. That’s pretty incredible for VBScript and a whole mess of nested include files.
So, are exceptions the best thing to squeeze their way between a couple of curly braces? I wouldn’t say that, but they make things better in the worst case, and when you have to deal with the worst case every day, that is a very good thing.
I’ve updated the flightpath app. After adding more realistic lighting, I got the lighting and rendering to work in video mode. Currently creating a video happens in script with calls to create the file, capture a screen and close the file. Ideally this should be handled externally to the model that is being investigated. Once I get objects created for all the display windows and properties, this should be much easier to do. In the mean time I will have to get by.
I’ve created 5 videos that highlight different kinds of interference patterns generated by the same functions superimposed on each other. In the first 2 videos the functions are added and subtracted from each other. In the third they are multiplied, and in the fourth and fifth, the added and subtracted models are squared.
additive interference
subtractive interference
multiplicative interference
additive squared interference
subtractive squared interference
FYI: these videos require a DIVX codec to playback properly.