Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

Re: streaming problem and thread freeze

Show all headers | View raw

On 05/10/2011 03:17 PM, Daniele Futtorovic wrote:
> On 10/05/2011 05:31, Lawrence D'Oliveiro allegedly wrote:
>> In message<iq9ai7$t2s$1@dont-email.me>, Daniele Futtorovic wrote:
>>
>>> Secondly, although it is only a minor thing and only my personal
>>> opinion, this:
>>>
>>> } catch (IOException ex) {
>>> log.severe(ex.getMessage());
>>> }
>>>
>>> is a *very* bad idea. Log the full stack.
>>
>> 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.

It's not really a bad thing nor even confusing to a reasonably-trained 
programmer to have 'catch' blocks all over the place, no more than the similar 
amount of decision blocks one needs for thorough, professional programming. 
Code that serves a purpose isn't bloat, and code that creates a reliable 
invariant isn't a digression.

If you can't stand the heat, get out of the kitchen.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

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