AssertionError...
This comes up more often in library code, where it's necessary to cleanly
close resources without losing exceptions. SneakyThrow increases the chances
that we'll do the right thing when it comes to exception handling. Please
don't use it, unless you really, really need to!
Cheers
On Tue, Nov 17, 2009 at 7:56 AM, Tim Ellison t.p.elli...@gmail.com wrote:
The difference I see, by just staring at the code and without running
it, is that if the 'thrown' Throwable that was caught earlier is not one
of the tested types (IOException | RuntimeException | Error) then the
On 17/Nov/2009 16:33, Jesse Wilson wrote:
On Tue, Nov 17, 2009 at 7:56 AM, Tim Ellison t.p.elli...@gmail.com wrote:
The difference I see, by just staring at the code and without running
it, is that if the 'thrown' Throwable that was caught earlier is not one
of the tested types (IOException
On Tue, Nov 17, 2009 at 8:53 AM, Tim Ellison t.p.elli...@gmail.com wrote:
Now I've gone back and looked, they were never the real last 10 lines of
the close() method. More a case of, rather than code it like this ... I
did it like this ..., right?
Yes, I named the wrong file. But for a few
On Tue, Nov 17, 2009 at 10:33 AM, Jesse Wilson jessewil...@google.com wrote:
On Tue, Nov 17, 2009 at 7:56 AM, Tim Ellison t.p.elli...@gmail.com wrote:
The difference I see, by just staring at the code and without running
it, is that if the 'thrown' Throwable that was caught earlier is not one
();
}
}
}
}
This new API shortens that last section dramatically:
if (thrown != null) {
SneakyThrow.sneakyThrow(thrown);
}
This comes up more often in library code, where it's necessary to cleanly
close resources without losing exceptions. SneakyThrow
