From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17350 invoked by alias); 21 Mar 2008 02:26:02 -0000 Received: (qmail 17342 invoked by uid 22791); 21 Mar 2008 02:26:02 -0000 X-Spam-Check-By: sourceware.org Received: from wx-out-0506.google.com (HELO wx-out-0506.google.com) (66.249.82.238) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 21 Mar 2008 02:25:44 +0000 Received: by wx-out-0506.google.com with SMTP id s18so1345226wxc.14 for ; Thu, 20 Mar 2008 19:25:42 -0700 (PDT) Received: by 10.114.110.12 with SMTP id i12mr4920199wac.73.1206066341986; Thu, 20 Mar 2008 19:25:41 -0700 (PDT) Received: by 10.114.120.5 with HTTP; Thu, 20 Mar 2008 19:25:41 -0700 (PDT) Message-ID: Date: Fri, 21 Mar 2008 02:26:00 -0000 From: "Jason Cipriani" To: "Ted Byers" Subject: Re: try, finally Cc: gcc-help@gcc.gnu.org In-Reply-To: <457283.62826.qm@web88308.mail.re4.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457283.62826.qm@web88308.mail.re4.yahoo.com> X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2008-03/txt/msg00208.txt.bz2 Ted, I can't respond to everything right now, because I somehow managed to spend a full hour typing that last email. Hopefully some of what you say here, I have addressed there. There are two things in particular that I want to point out, though: The first: On Thu, Mar 20, 2008 at 10:49 AM, Ted Byers wrote: > Look, C++ has a whole suite of error detection and > handling capability. To use only exceptions is > somewhat like a carpenter having only a hammer trying > to hammer screws into place. If all you have is a > hammer, everything looks like a nail. But if you have > a set of screw drivers in your belt along with your > hammer, you'll use the right tool for the job. I believe I addressed this in my recent post. Using *only* exceptions would be a mistake. However, using error codes when exceptions can make things a lot simpler is also a mistake. The same goes both ways, "to use only error codes" fits into that analogy as well. There is a happy medium, and there are some situations where exceptions are more appropriate, and some where error codes are more appropriate. I take the approach of using exceptions unless I am forced to do something else, for example, the following situations: 1) Where performance is critical and exceptions have too much overhead. For example, if I was writing, say, a function that intersected a ray with a cylinder to use in a ray tracer implementation (or whatever), I would certainly not have that function thrown an exception if the ray did not intersect. 2) Where exceptions simply can't be used, such as in the boundary conditions mentioned above (especially across C boundaries). In this case, error codes are the best tool, and eventually they can be used to throw exceptions at a higher level if that is appropriate. I do not support using only exceptions. I also do not support using only error codes. In college, my friends used to call me Jason "Use the Right Tool For the Job" Cipriani. Well, maybe not. My original question about SEH was in a situation where SEH was a great tool for what I was trying to do. The book I just wrote about exceptions is intended only to show a good example of when exceptions are a better tool than error codes. The second thing is: > You're throwing everywhere. It is almost as if you > have a bad case of cyber-stomache flu. LOL. :-) It's better than cyber-diarrhea I suppose. > You are using > exceptions for flow control. I need to address this because it is not correct. I am using exceptions for *error handling* flow control. All error handling involves some sort of trivial flow control. However, do not confuse this with using exceptions for things like this: void DoSomething (vector &data) { int i = 0; try { while (true) { DoSomethingElse(data[i]); ++ i; if (i >= data.size()) throw int; } } catch (...) { } // do more stuff } NO. DO NOT DO THAT! (heh). That is *not* what exceptions are for at all. Exceptions are for error conditions that must result in special handling. I hope that I haven't given an example otherwise -- if I have I didn't intend for it to look that way. > That is not what they're > there for. Eljay's brilliant description of return > codes (including especially his smart return code > objects) is a much better option. And don't forget > assertions have a valid role in many cases also. Assertions are good for stating assumptions; they notify you when your assumptions are invalid and also double as documentation when reading code. However, doing something like this: FILE *f = fopen("file", "r"); assert(f); Is *not* a good use for assert(), for hopefully obvious reasons. I used fopen() as an arbitrary example, substitute your favorite function instead. I have read the rest of your reply, but I can not respond to it right now. I apologize. But I did read it. Thanks. Jason