...it is easy to become frustrated and angry, and it is even easier to Post in anger on a Forum (I've seen it all too often, as I'm sure others have as well... I might have even done something like that once or twice). However, what's not easy is backing up a step or two and regrouping.
:roll:
I know it was a long long time ago, but I used to be a programmer myself. When I coded, and anyone on my team coded, we would "trap" any errors when they occurred.
The reason I mention this here is that Adobe seems to believe that having their programs "crash" and "dump" is just "OK."
It isn't.
The frustration and anger mentioned above I believe is justified... maybe not that it is directed here specifically, but, simply put, programs are not supposed to crash. If a hard drive fails, there are ways of handling that error, ditto any other corruption of file, buffer overflows, unexpected variables, etc. Sure, it isn't "sexy" to recode all of your existing routines to handle unexpected errors, it is more "sexy" to add new functions. But... that isn't what makes great programs; great programs are programs that give the user as much information as possible, then exit politely. Adobe isn't guilty only with this lightroom bug which also plagues me (and I never used that other raw program), they are guilty with other programs as well, including their entry level premier elements version 4 which crashes with the faintest provocation.
Yes, I know that we live in a different world now, where sexy usually beats out reliability. But, honestly, how sexy is it when a bride can't get her output because the 3 days of changes I just made in Lightroom are no longer available because the program crashes without telling me why it is crashing?
Adobe, are you listening?
The moral of the story is, factor in error handling with the project plan. It may be more work in the beginning, but saves SO MUCH time in the end, and not just for the customers, for the programmers too!
Gene
