Lots of discussions about that

Post #199,069 by FuManChu 3/16/05 4:38:14 PM Reply	Lots of discussions about that Google for "return values versus exception" and similar terms. The biggest advantages are that 1) you don't have to propagate return values outward when you decide to catch errors further from their occurrence, and 2) people are lazy and forgetful, and won't test for error-values. But then, they're lazy with exceptions, too, and tend to silence them.
Post #199,071 by CRConrad 3/16/05 4:43:24 PM Reply	That only goes for one kind of exceptions! Rober t s manchu writes: Google for "return values versus exception" and similar terms. The biggest advantages are that 1) you don't have to propagate return values outward when you decide to catch errors further from their occurrence, and 2) people are lazy and forgetful, and won't test for error-values. You can put "site:iwethey.org" into your Google query, if you want... :-) But then, they're lazy with exceptions, too, and tend to silence them. That problem only exists with Java's braindead "checked" exceptions... As one would have thought you'd know, after the extensive discussions we had here last year. [link\|mailto:MyUserId@MyISP.CountryCode\|Christian R. Conrad] (I live in Finland, and my e-mail in-box is at the Saunalahti company.) Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link\|http://z.iwethey.org/forums/render/content/show?contentid=71575\|Ashton Brown]
Post #199,095 by FuManChu 3/16/05 5:55:46 PM Reply	What does the "checked" mean to you? Checked exceptions only mean "those which the compiler checks". Runtime exceptions suffer from the same problem--lazy programmers tend to silence them (at runtime) with code like: `\ntry:\n do_stuff()\nexcept:\n pass\n` ...or worse tricks, like raising a new error (with less information, and discarding the inner stack trace). The Sig: "Despite the seemingly endless necessity for doing so, it's actually not possible to reverse-engineer intended invariants from staring at thousands of lines of code (not in C, and not in Python code either)." Tim Peters on python-dev
Post #199,078 by drewk 3/16/05 5:18:00 PM Reply	But he's saying that you should use both Throw exceptions when it's a "serious problem" that should halt page execution. Return an error object when it's a "routine event" that can be handled in the calling code and continue. It seems to me you can do both with exceptions. === Purveyor of Doc Hope's [link\|http://DocHope.com\|fresh-baked dog biscuits and pet treats]. [link\|http://DocHope.com\|http://DocHope.com]
Post #199,091 by Arkadiy 3/16/05 5:40:27 PM Reply	My rule of thumb is, when the return value has an obvious "error mode", such as returning "" for file name (or -1 for collection size), and when the error _must_ be handled by the caller, return a value. If either of those conditions is not met, throw an exception. -- And what are we doing when the two most powerful nations on earth -- America and Israel -- stomp on the elementary rights of human beings? -- letter to the editor from W. Ostermeier, Liechtenstein
Post #199,096 by admin 3/16/05 6:04:02 PM Reply	Pick one and stick with it. I'd go with exceptions for the reasons that Robert gave. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #199,097 by FuManChu 3/16/05 6:05:51 PM Reply	You can do both (or more accurately: either) with or without Exceptions break the normal flow of control (by propagating outward), and should therefore be used when you want to break flow. When you don't want to, use a return value. It's common to see either approach being abused, but it's rarely a deal-breaker.

Welcome to IWETHEY!