Yes! no one in any other language would write this code. This code
snippet is almost always wrong.
On Sep 22, 9:03 am, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> 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 <ricky.clark...@gmail.com> 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 ♔ <ced...@beust.com>
>
> >> On Wed, Sep 22, 2010 at 7:38 AM, Kevin Wright
> >> <kev.lee.wri...@gmail.com>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 javapo...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups
> >> .com>
> >> .
> >> 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 javapo...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups
> > .com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/javaposse?hl=en.
>
> --
> Kevin Wright
>
> mail / gtalk / msn : kev.lee.wri...@gmail.com
> 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 javapo...@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
