File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Agile and Other Processes and the fly likes Code Craft Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Code Craft" Watch "Code Craft" New topic
Author

Code Craft

Bill Johnston
Ranch Hand

Joined: Nov 17, 2005
Posts: 201
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.

~Bill


~Bill
Pete Goodliffe
author
Greenhorn

Joined: Feb 02, 2007
Posts: 24
Hiya,

Hopefully you've seen links to the information you want by now!

Perhaps your best bet is to check this link out:
http://www.nostarch.com/codecraft_toc.htm
Bill Johnston
Ranch Hand

Joined: Nov 17, 2005
Posts: 201
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,

~Bill
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Code Craft