Worse still is when IDEs do it! I believe that eclipse favours:
try {
...
} catch(Exception ex) {
ex.printStackTrace();
}
and that is so very, very wrong. A desperate hack forced upon us by the
nature of checked exceptions.
On 22 September 2010 15:58, Ricky Clarkson <[email protected]> wrote:
> The real issue behind checked exceptions is that not every caller will want
> to catch the exception or mention it in its throws clause. An exception
> that is recoverable for you might not be for me.
>
> Most defenders of checked exceptions will happily state that the caller
> doesn't have to handle it, they can just use throws. Presumably they are
> unfamiliar with the concept of implementing an interface that is not
> specific to the current method, e.g., Runnable.
>
> My preferred solution is to use unchecked exceptions by default, and then
> reading the stack trace to know where problems lie. For cases I know about
> and know I can recover from, I do so, but not using exceptions (e.g.,
> passing in a User object that has a getUsernameAndPasswordFor(URL url)).
>
> One of the biggest problems I see in the code I work with is that many
> developers do things like catch (Exception e) { log.debug(e); } and don't
> set the logger to debug level, or catch (FileNotFoundException) { //do
> nothing, this is impossible }, and of course the insane SwingWorker, which
> swallows exceptions unless you override get() and call done() within it
> (which throws no fewer than 2 checked exceptions itself).
>
> 2010/9/22 Cédric Beust ♔ <[email protected]>
>
>>
>>
>> On Wed, Sep 22, 2010 at 7:38 AM, Kevin Wright
>> <[email protected]>wrote:
>>
>>> That's very much the point... If a file can't be found when you're first
>>> trying to open it, then that's normal.
>>> If a file can't be found after you've already been working with it, then
>>> that's exceptional.
>>>
>>
>> The semantic distinction that you're observing is correct, but
>> distinguishing the two cases doesn't make practical sense.
>>
>> Whether the file is not present at opening time or disappears while you're
>> using it, you will probably want to handle this error the same way, so
>> throwing the same exception and catching it a little higher in the stack
>> frame makes sense to me.
>>
>> --
>> Cédric
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "The Java Posse" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]<javaposse%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/javaposse?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<javaposse%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
--
Kevin Wright
mail / gtalk / msn : [email protected]
pulse / skype: kev.lee.wright
twitter: @thecoda
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
