A subject dear to my heart; catchy title; excellant choice for the cover art. Book has good reviews, but I'd like to get a chance to read some of it. Am I missing something - I don't see a link to any chapters or TOC.
Reading through Chapter 6 (not quite finished yet) I have a few questions, one or more which might be dissagreements - but might not be in the case of a misunderstanding:
Q#1 (Under the subject of Error modeling: ---- The termination model: Execution continues after the handler that caught the exception. This behavior is provided by C++, .NET, and Java.
The resumption model Execution resumes where the exception was raised. The former model is easier to reason about, but it doesn�t give ultimate control. It only allows error handling (you can execute code when you notice an error), not fault rectification (a chance to fix the problem and try again).
It's this quote here that I question: "The former model is easier to reason about, but it doesn�t give ultimate control. It only allows error handling (you can execute code when you notice an error), not fault rectification (a chance to fix the problem and try again)."
Q#2 (under the heading of WHISTLE-STOP TOUR OF EXCEPTION SAFETY) ---- Now under the subject of the "Nothrow guarantee"
"In the presence of an exception, object destructors are called automatically as the stack is unwound. Raising an exception while handling an exception is not permissible."
... I point to the code above again to questions this
This quote below I heartily agree with: ---- "KEY CONCEPT Handle each error in the most appropriate context, as soon as you know enough about it to deal with it correctly."
Q#3 (under the subject Reporting: ---- "Of course, this kind of reporting depends on whether or not the program is interactive. Deeply embedded systems are expected to cope on their own; it�s hard to pop up a dialog box on a washing machine."
This is not always the case. Many times job scheduling applications will read the feedback from each process/step and base decisions on what to do next. This was/is the case with the old IBM JCL procedural streams and is every bit as tru today with more modern job-scheduling software applications. Now there may be no Pop-Up box per-say ... but it is still not completely "expected" that each process "cope on their own". Now this might be a misunderstanding on my part, because you do use the word "system", not "process". Still, since the subject at hand is writting code for an application ... this might be misconstrued to mean "process", rather than an entire "system". Any comments?
One the whole, the reading is easy and understandable and the topic a very valid one. I wish you success; and best regards,