Yes, if you remove a checked exception from a method, then callers
that handle this exception no longer get the benefit of a compiler
error. However, removing checked exceptions from API is somewhat rare.
Also, if you perform the 'remove this exception' refactor with a
compiler tool instead of by editing it out by hand, this tool can
chase down callers and report back which callers appear to have
superfluous handlers.
On Sep 23, 9:41 pm, Ricky Clarkson <ricky.clark...@gmail.com> wrote:
> So when you change a method's throws clause the compiler won't alert you to
> change the callers.
>
> Yes, we're discussing an idea. The things that seem obvious showstoppers to
> me you seem to think are just my being picky. Square wheels are an idea
> too.
>
> On Thu, Sep 23, 2010 at 7:11 PM, Reinier Zwitserloot
> <reini...@gmail.com>wrote:
>
>
>
> > Obviously, when sneakyThrows becomes part of the language, you remove
> > the compile-time restriction that you can't catch checked exceptions
> > that nothing in the try body throws. We're discussing an idea here, I
> > didn't feel the need to submit an entire spec.
>
> > On Sep 23, 12:14 pm, Ricky Clarkson <ricky.clark...@gmail.com> wrote:
> > > Reinier,
>
> > > Without rewrapping you would get into situations where:
>
> > > * you call foo() and foo() calls bar().
> > > * bar() throws IOException
> > > * foo() doesn't, via some syntax like foo() spits IOException, foo()
> > rethrow
> > > IOException, etc.
>
> > > Now at your current point you decide that you know better than foo(), and
> > > want to catch and handle the IOException. You can't, it's a compile time
> > > error to catch a checked exception that the compiler believes cannot be
> > > thrown.
>
> > > Rethrowing might be a better option, and does not need to add stack
> > frames.
> > > You can override Throwable.fillStackTrace to do nothing.
>
> > > On Thu, Sep 23, 2010 at 11:06 AM, Reinier Zwitserloot <
> > reini...@gmail.com>wrote:
>
> > > > The majority of java programmers have standard rules that ALL blocks
> > > > must be braced.
>
> > > > The *vast* majority of java programmers have standard rules that ANY
> > > > non-trivial block must be braced, and will only keep unbraced the
> > > > simplest of ifs (without elses), whiles, and fors.
>
> > > > That would mean a very very tiny fraction is even going to try and
> > > > write try statement catch (exception(s) e) { ... }.
>
> > > > Is this going to lead to shorter code? After your try version, you'd
> > > > have to do a check on whether se or oe isn't null, which is just as
> > > > much complication in the end, except now you've introduced even more
> > > > opportunity for the programmer to screw up their exception handling,
> > > > and you've introduced 2 very different ways of accomplishing the same
> > > > thing, always a bad idea if it can be avoided.
>
> > > > As I've been proposing with an official coin-dev submission for rather
> > > > a long time now: The right way out of this dilemma is to offer
> > > > programmers the option to explicitly state that they want to ignore an
> > > > exception. This means it gets bubbled up as usual but they don't have
> > > > to declare it as part of their "throws" signature. Something like
> > > > Ricky's "throws private" but with different syntax and without
> > > > rewrapping. Because java really doesn't need stack traces that grow
> > > > even longer.
>
> > > > On Sep 23, 3:12 am, Josh McDonald <j...@joshmcdonald.info> wrote:
> > > > > Hey guys, I'm not weighing in on checked v unchecked, just a syntax
> > sugar
> > > > > idea!
>
> > > > > We've got two ifs:
>
> > > > > if (foo)
> > > > > bar();
>
> > > > > and
>
> > > > > if (foo) {
> > > > > bar();
>
> > > > > }
>
> > > > > So why not introduce a cut-down syntax for common exceptions?
> > Something
> > > > like
> > > > > this:
>
> > > > > try file=File.open(...) catch(SomeException se, OtherException oe);
>
> > > > > Which would be expanded out by the compiler to this:
>
> > > > > SomeException se = null;
> > > > > OtherException oe = null;
>
> > > > > try {
> > > > > file = File.open(...);
>
> > > > > } catch (SomeException e) {
> > > > > se = e;
> > > > > } catch (OtherException e) {
> > > > > oe = e;
> > > > > }
>
> > > > > And you can check the contents of the exception or not at your
> > leisure.
>
> > > > > Thoughts?
>
> > > > > --
> > > > > "Therefore, send not to know For whom the bell tolls. It tolls for
> > thee."
>
> > > > > Josh 'G-Funk' McDonald
> > > > > - j...@joshmcdonald.info
> > > > > - http://twitter.com/sophistifunk
> > > > > - http://flex.joshmcdonald.info/
>
> > > > --
> > > > 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>
> > <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.
--
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.
