Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Daniele Futtorovic Newsgroups: comp.lang.java.programmer Subject: Re: streaming problem and thread freeze Date: Wed, 11 May 2011 18:55:53 +0200 Organization: A noiseless patient Spider Lines: 48 Message-ID: References: <005a9e79-36fe-4bf1-aa1d-bda3a5aaebf2@glegroupsg2000goo.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 11 May 2011 16:55:52 +0000 (UTC) Injection-Info: mx01.eternal-september.org; posting-host="Ifi0zMlPPHi1edxcIMhOmQ"; logging-data="24135"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18BDjuKrim+e8LLpdJoqrEI" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 In-Reply-To: Cancel-Lock: sha1:2PwyY2dNzELzYpoyXhyrKCpQZmo= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3978 On 10/05/2011 23:26, Lew allegedly wrote: > On 05/10/2011 03:17 PM, Daniele Futtorovic wrote: >> On 10/05/2011 05:31, Lawrence D'Oliveiro allegedly wrote: >>> It would be so much easier if you could simply not bother to catch the >>> exception at all, and let your program crash with a full stack trace. >> >> It would be yet much easier, as you perhaps one day will learn, to >> realise >> that checked exceptions are not a bother, but an almost invaluable tool. >> >> And in cases you have to do something dirty, you can still simply >> throw an Error. > > You raise a good, if classically controversial, point, the overarching > question of how properly to use exceptions. I, too, am partisan to the > checked exception from two perspectives - that of the maintainer, and > that of the API designer. You don't have to use them, given the rich > hierarchy of Throwables, but they sure can be useful. > > Complaints about checked exceptions come pretty much exclusively from > programmers using APIs that require'em. Hmm. I recommend to such folks > that they consider a question, "What purpose does this particular > checked exception serve in the method contract?" > > Whether you agree or not, the API designer had an answer to that > question. They have ensured that all clients benefit from their reasoning. > > API designers that make different decisions might use runtime exceptions > or some other mechanism. Corrollarily, while it is indeed the task of API design that puts the problem of which exceptions to throw when and how right in one's face, I would argue that it is nevertheless primarily API /usage/ that teaches one the virtue of a well-thought-out exception design -- perhaps through the bother of not-so-well-thought-out ones. It is healthy to question the usage of Exceptions made by an API every time one uses a new one. Question it, ponder whether the way things are done actually help you, or bother you, and how they could be improved. BUT, give the API writers the benefit of the doubt. Chances are they had a bad reason for doing what they did. Chances are they had a good reason. But they almost certainly /had/ a reason. Find that reason, and find out what it's worth. Thus thy craft will blossom. -- DF. An escaped convict once said to me: "Alcatraz is the place to be"