I know this is an older post from earlier this year, but the Exception vs Error code debate is a hot one and is always relevant, and may never even be solved.. So I am replying... yes I realize it is an old post.
In case of using someone-else-written-library, follow what the author designs the library
behavior as.
And this is the exact problem with exceptions, it assumes the author designs the library correctly and it assumes the author of the library is literally a psychic who can figure out how his library is going to be used in the future.. Library authors are not psychic and cannot anticipate how people are going to use the library. Often the library is designed wrong because 99 percent of people aren't even smart enough to understand exceptions or how those exceptions will always be correctly sprung up in a program..
For those who haven't researched this subject enough I suggest looking up Joel Spolsky's comments on the subject using google... And also Taylor Hutt.
http://www.joelonsoftware.com/items/2003/10/13.htmlException programming is near impossible to get right... it takes a genius to get it right, and library developers that are even geniuses never get it right. Joel Spolksy has some further info on why this is so. Most people read Spolsky's article and completely miss his point and then go on to continue using exceptions without even getting his point... it's all over the internet, the flamewars are rampant on the subject... Googling this info is helpful if you can put on your thinking cap a bit and understand the subject. It's not an easy subject to understand.
Exceptions are not the holy grail that solve problems magically.. they often create more problems then they try to resolve. You literally have to be a psychic as a library author to know how to write your exceptions, you have to anticipate how people are going to use your library.. and since libraries are bottom up (people use them for all sorts of things) it is impossible to design a library correctly using exceptions because you cannot anticipate what and how people are going to use your library. Error codes allow the library to be used how the person wants, whereas exceptions force a specific way (and it is often a wrong way) of error handling on to the user. It's bottom up design vs top down "I know Everything about my end users" attitude.
Plus if your library is cross language (like a DLL) throwing exceptions in pascal can never be dealt with in another language since exception systems are incompatible across languages, whereas errors are completely library compatible with each other... That's why C programmers rule the world, because they provide us with their libraries for us to wrap and use, whereas pascal just keeps everything to itself and doesn't know much about DLL's or api's.. It's all OOP and exceptions with pascal nowadays and objects/exceptions in pascal are not compatible with C or other languages, so no one reuses pascal code from other language. Continuing pascal's slow but sure death.
Example: To the problem of readonly file I explained before. At the time I'm saing the file I want to catch EUnableToSaveReadOnly file. If the exception is caught I need to update the flag and try saving of the file again. But I don't want to handle EAcccssViolation, if I catch this one, I've to re-rise it. As a result I'm getting two logical kind of exceptions- the error exceptions (the exceptions I expect to receive in this part of the algorithm) and exceptional exceptions (the exceptions I don't expect).
But now these exception handling rules are within the main logic. So what's the benefit?
Not only that, but when you have file opening issues you should NEVER let the end user see an annoying obnoxious exception message.. it's should be a clean message that says "file xyz.txt not opened in abc directory"... not some bizarre cryptic exception
scary message that frightens the user such as EFileNnotFoundError &*&*&*#$ STACK TRACE at address *&&*$#
See my comment on that here:
http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Improve-or-Ditch-The-Rude-ExceptionsException error messages are not something end users enjoy seeing at all, and end useres will quickly avoid using your software posting bad reviews of it after they get their first obnoxious fearful exception message blurted out to them... It's the typical java exception error junk that makes me dislike Java apps quite a bit.. (there are other issues with Java that I dislike just as much, but that is beyond the scope of this post). Java programmers are confused about what an error is and what an exception is, because no one has scientifically stated what the difference between exceptions and errors are...
Some quotes to remember (also in my wiki) and study (and you
really have to think about this
carefully to understand it)
"Exceptions are only generated in the expectation that they will eventually be handled. For this to be possible, a routine which can generate an exception must declare this fact as part of its specification. Full details of all of the consequences of the exception must be provided if it is to be handled effectively. " --Prof. Andrew P. Black, Doctoral Thesis
"If you have failed the contract, then an unexpected situation has arisen -- it is fundamentally IMPOSSIBLE to program for unexpected situations. Let me restate that: It is impossible to handle unexpected errors!
The only errors that you can handle are EXPECTED errors, and in that case they should be written into the contract. " --Taylor Hutt, Usenet Post