Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.lang.java.programmer > #3978

Re: streaming problem and thread freeze

Show all headers | View raw

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"

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

streaming problem and thread freeze Fly <flavio80@gmail.com> - 2011-05-09 07:56 -0700
  Re: streaming problem and thread freeze Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-09 20:08 +0200
    Re: streaming problem and thread freeze Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-10 15:31 +1200
      Re: streaming problem and thread freeze markspace <-@.> - 2011-05-10 04:47 -0700
      Re: streaming problem and thread freeze Lew <noone@lewscanon.com> - 2011-05-10 08:52 -0400
      Re: streaming problem and thread freeze Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-10 21:17 +0200
        Re: streaming problem and thread freeze Lew <noone@lewscanon.com> - 2011-05-10 17:26 -0400
          Re: streaming problem and thread freeze Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-11 18:55 +0200
        Re: streaming problem and thread freeze Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-11 14:06 +1200
          Re: streaming problem and thread freeze Lew <noone@lewscanon.com> - 2011-05-11 09:02 -0400

csiph-web