Error handling in software is something which is traditionally difficult to pin down and do right. As I’m at work, I won’t get into a big discussion about errors (though I could). Mostly, I want to keep around a pointer to this slashdot post which describes a brilliant method of letting the user know exactly why something failed. Basically, it’s a semantic stack trace — each layer of the software contributes its understanding as to what went wrong, as a user-readable string.
You know, I would really like to work in a language which has error handling properly figured out. Though this may stem from my relative inexperience with exceptions, they’ve always seemed kind of wrongheaded to me. An error-handling policy is generally a pretty high-level thing, and most errors occur in very low-level places. Exceptions as they work in current languages that I’ve seen seem to encourage a fairly shallow, “well, my app isn’t going to have a fucking clue what this low-level error means, so I’d better handle it here.” What should happen is that the exceptions should build up — “I have well-defined errors, and I am going to transform the error I got from this lower level into one a higher level can understand, while not throwing away valuable information about the low-level cause of the error.” The semantic stack trace appeals to me in this way.
Of course, then you get into the nasty localization issues. I’d also really like to work in a language which has localization figured out. =]