Throwables.propagate being deprecated?

[theco...@googlemail.com]

I've noticed that Throwables.propagate is being deprecated, along with propageteIfInstanceOf and propagateIfPossible. I think these are useful methods, and there doesn't seem to be a direct replacement. What's the thinking behind deprecating these methods?

SimonC

[Chris Povirk]

We hope to write more about this someday, but for now, the best we have is https://github.com/google/guava/wiki/ThrowablesExplained#uses-for-throwablespropagate

[Kevin Bourrillion]

Everyone,

If anyone is interested in having a constructive discussion about this deprecation (or perhaps about the difficulties of working with a library that ever deprecates things at all?), we're always open to that.

Thanks!

On Wed, Jan 18, 2017 at 8:06 AM, <emanue...@gmail.com> wrote:

I will probably rip out Guava from everywhere I've used it. It just isn't worth the hassle of dealing with Google libraries. I'm sick of having inexperienced engineers tell me how to write code.

On Friday, July 29, 2016 at 7:04:52 AM UTC-4, theco...@googlemail.com wrote:

I've noticed that Throwables.propagate is being deprecated, along with propageteIfInstanceOf and propagateIfPossible. I think these are useful methods, and there doesn't seem to be a direct replacement. What's the thinking behind deprecating these methods?

SimonC

--
guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guava-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/7ab8af88-20dc-4119-85eb-bbf49f70740b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com

[sha...@google.com]

> I'm sick of having inexperienced engineers tell me how to write code

I'll bite - Inexperienced? Come on... You might not like their decisions but you most definitely can not say that they are inexperienced.

I actually appreciate the Guava's team dedication to clean up parts of the library as it evolves. It might be a wrong move in this specific case (in your opinion) but as Kevin said, they are open to discuss this.

If I were you, I'd just copy the code for Throwables.propagate into a new class and simply call your function instead of Guava's. From a quick look, it looks like there's not too much code you'll need to copy over.

-Shahar

On Wednesday, January 18, 2017 at 9:54:11 AM UTC-8, emanue...@gmail.com wrote:

Guava is used everywhere by everybody.  Anything that is deprecated has a huge impact on a very large number of engineers.  It may as well be part of the JDK.

Throwables.propagate is used very effectively to replace silly catch blocks that add absolutely no value to anybody.  Without using propagate I have to add a few lines of extra exception handling for including some conditionals.  My company has a 80% unit test code coverage rule that includes catch blocks.  That means that I need to provide additional unit tests for every instance of Throwables.propagate that I replace, to make sure I don't cause any outages.

It isn't just a matter of replacing 1 line of code, it's replacing 1000's of lines and copy-pasting thousands of unit tests.  I literally have to change thousands of them. Yes - deprecating Throwables.propagate pissed me off. Sorry, I am in a bad mood - don't even get me started on Guava collections and nulls.

There's nothing wrong with Throwables.propagate. If there was something wrong with it, then I would agree that it must be deprecated and replaced.  If there's no pressing reason to get rid of it, and it's been in production systems for many years, you should absolutely keep it. 

On Friday, July 29, 2016 at 7:04:52 AM UTC-4, theco...@googlemail.com wrote:

[David Beaumont]

You could always write your own replacement function for this though, right (and it's not like it's going away yet anyway) ?

I think that a fair number of the places (that I've seen) which used Throwables.propagate() weren't ""replacing silly catch blocks that add absolutely no value to anybody"". In a lot of cases I felt they were conflating multiple, semantically different, things into one.

I personally think it's valuable to think about the places in code where checked exceptions become unchecked. They're the places where you're throwing you hands up and saying you can't reasonably continue (where someone else in different code could perhaps recover). It's part of the shape of an API and defines its responsibilities. I think Throwables.propagate() was encouraging a lot of people to ignore these issues.

Just my $0.02,

    David

--

guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guava-discuss+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/f72a1f4e-1283-45f1-bd5e-02a62d8d5fe2%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

David Beaumont :: Îñţérñåţîöñåļîžåţîờñ Libraries :: Google
Google Switzerland GmbH., Brandschenkestrasse 110, CH-8002, Zürich - Switzerland

[Alastair Donlon]

Just to back up the approach Guava is taking over how the JDK works - look at java.util.Date. I wish they'd *at least* mark it @Deprecated if only to let newcomers know that this is not the droid... sorry, class... they're looking for.

A.D.

To unsubscribe from this group and stop receiving emails from it, send an email to guava-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/f72a1f4e-1283-45f1-bd5e-02a62d8d5fe2%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

David Beaumont :: Îñţérñåţîöñåļîžåţîờñ Libraries :: Google
Google Switzerland GmbH., Brandschenkestrasse 110, CH-8002, Zürich - Switzerland

--

guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to guava-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/CAKxGnns0O_p77MHCHskT7gMZLTQtXvvG4WLXpfbxAF2OR%2BAzWw%40mail.gmail.com.

[Thomas Broyer]

> Guava is used everywhere by everybody. Anything that is deprecated has a huge impact on a very large number of engineers. It may as well be part of the JDK.

Guava has a *very clear* deprecation lifecycle, basically saying that if you use Guava you should update your lib/app at least every 18 months or so to not get caught by API removals.

The problem is NOT Guava, it's people not keeping their deps up-to-date, not living by the standards they opted in to when choosing Guava in the first place, ones we could call *ahem* "inexperienced developers".

[Raymond Rishty]

Kevin and the other Guava guys, thanks for your work here, for sharing for the world to use, and the extraordinary careful attention you pay to API design. Looking at your design, listening to your opinions on the topics, and watching the library evolve makes me a better designer.

On the topic, I admit I grumbled a little at the thought of Throwables.propagate being deprecated, but I refactored it out, and in doing so realized my use of it was an abuse. The method combined rethrowing both checked and unchecked exceptions in a way that was completely unnecessary for me--I could easily just wrap in a RuntimeException or rethrow the existing exception. And more to the point, the activity of refactoring that out made me evaluate if I really was handling exceptions properly, or just rethrowing to be lazy about it. I found a few cases of the latter. In the end deprecating this overused method made me more careful and improved my code.

So, thanks, guys, for taking away that thing I was using. 

Ray

--
guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss

This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guava-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/4aa5a7d2-3079-4560-b44a-654f522556f9%40googlegroups.com.

[Kevin Bourrillion]

Thanks for all the support, folks.  I will say that Emanuel definitely made some very valid points (on the second try :-)) and the team is pondering them fairly.

We do take removals seriously. One piece of evidence: before we remove anything, we actually take on the burden ourselves of fixing every last caller of that code across all internal Google Java projects. We have some nice tools to help with that, but it's still quite a hassle. It's time we could instead prefer to sit in our tower and make decisions in isolation from all actual lived user experience. But instead we make sure we're willing to put ourselves through the change first before asking anyone else to suffer it.

Does that mean we can never make a mistake: of course not. Personally I feel proud when I just manage to make different mistakes instead of the same ones repeatedly.

Anyway, as regards, the propagate methods:

1. We will do a better job of documenting why we feel it's a good idea not to use them

2. We very likely won't change our minds on that part

3. There is still room for us to decide that actual deprecation is too strong a response (however, no promises)

4. We have some news coming "soon" that should make deprecations a little easier to deal with ......

To unsubscribe from this group and stop receiving emails from it, send an email to guava-discuss+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/4aa5a7d2-3079-4560-b44a-654f522556f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to guava-discuss+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/CAODfdDeXJu%2BkymaLK4PntOdhDH0tc47hOy_qNy8asJ5TT0aSQg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Kevin Bourrillion]

Thanks Emanuel. We appreciate your input bigly.

On Thu, Jan 19, 2017 at 8:07 AM, Emanuel Bulic <emanue...@gmail.com> wrote:

I want to apologize for my Trump-like comment, and I am happy that my second try was more useful. thanks for putting up with my frustration. I do not have permission to share our usage metrics around Guava and more specifically, our use of Throwables.propagate, but suffice it to say, I did not exaggerate the impact it will have. If you would like, I can try to get permission to share this data with you.

Thanks

--Emanuel.

You received this message because you are subscribed to a topic in the Google Groups "guava-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/guava-discuss/QvModYS4uIM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to guava-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/CAGKkBksKCoBwQqgcfMujuPoTNg81dZ290dyLPA%2BXFnJVVfAu-A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Justin Sampson]

Emanuel's comment about unit tests particularly caught my eye. I've actually been playing with 100% coverage on my current (smallish) project. For boilerplate catch blocks, the approach I've landed on is the extract the try-catch block itself into a method with its own unit test so that it doesn't have to be tested everywhere it occurs, like this:

 

interface IOExceptions<T> {

 

  T get() throws IOException;

 

  static <T> T areImpossibleIn(IOExceptions<T> supplier) {

    try {

      return supplier.get();

    } catch (IOException e) {

      throw new AssertionError(e);

    }

  }

}

 

Which can then be used like this:

 

IOExceptions.areImpossibleIn(() -> somethingThatTakesReader(new StringReader("foo")));

 

Cheers,

Justin

To unsubscribe from this group and stop receiving emails from it, send an email to guava-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/4aa5a7d2-3079-4560-b44a-654f522556f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to guava-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/CAODfdDeXJu%2BkymaLK4PntOdhDH0tc47hOy_qNy8asJ5TT0aSQg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

 

--

Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com

--
guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---

You received this message because you are subscribed to a topic in the Google Groups "guava-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/guava-discuss/QvModYS4uIM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to guava-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/CAGKkBksKCoBwQqgcfMujuPoTNg81dZ290dyLPA%2BXFnJVVfAu-A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

 

--

Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com

--

guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to guava-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/CAGKkBkv%2BSxwYjJTC5VoVC6UVy5QN0PDGmPqsrEcdKTdsDNjO6A%40mail.gmail.com.

[jgm...@gmail.com]

Removal of Throwables.propagate is going to be a huge pain, requiring refactoring throughout huge swaths of our code.

Cases where we use Throwables.propagate:

* Implementations of interfaces/classes used by unit tests, where the appropriate handling of any exception is to fail the test.

* Checked exceptions that are extremely unlikely to ever be thrown, such as an IOException from reading an InputStream backed by a static buffer,  WrappingExecutorService.wrapTask(Runnable), or doing reflection on classes with known content.

* Situations where the appropriate handling is "cause the server to fail to start".

* Unwrapping ExecutionException causes.

[Kurt Alfred Kluever]

Throwables.propagate() was misused a _lot_ inside of the Google codebase. The most common misuse was:

  Throwables.propagate(knownCheckedException)

If you _know_ you have a checked exception, this method is exactly the same as throw new RuntimeException(knownCheckedException).

The only time that the method was useful is if you were in the _very_ small minor of cases where you don't know if your throwable is checked or not.

We definitely need better docs explaining this though.

On Thu, Jan 19, 2017 at 5:06 PM, <jgm...@gmail.com> wrote:

Removal of Throwables.propagate is going to be a huge pain, requiring refactoring throughout huge swaths of our code.

Cases where we use Throwables.propagate:

* Implementations of interfaces/classes used by unit tests, where the appropriate handling of any exception is to fail the test.

I'm not sure why you'd need this in tests. Your test methods should just declare "throws Exception", which alleviates the need for a try/catch/propagate.

 

* Checked exceptions that are extremely unlikely to ever be thrown, such as an IOException from reading an InputStream backed by a static buffer,  WrappingExecutorService.wrapTask(Runnable), or doing reflection on classes with known content.

You should never be passing a known checked exception to Throwables.propagate (we saw this pattern inside of google as well). If you want to propagate a known checked exception, just "throw new RuntimeException(checkedException)".

 

* Situations where the appropriate handling is "cause the server to fail to start".

Again, throw a RTE wrapped around your checked exception.

 

* Unwrapping ExecutionException causes.

--
guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guava-discuss+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/9620ff9b-54ca-4d98-9450-50b04fba912f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

kak

[jgm...@gmail.com]

On Thursday, January 19, 2017 at 2:31:43 PM UTC-8, Kurt Kluever wrote:

We definitely need better docs explaining this though.

That would have been helpful if you had written such docs a few years ago.
 

On Thu, Jan 19, 2017 at 5:06 PM, <jgm...@gmail.com> wrote:

Removal of Throwables.propagate is going to be a huge pain, requiring refactoring throughout huge swaths of our code.

Cases where we use Throwables.propagate:

* Implementations of interfaces/classes used by unit tests, where the appropriate handling of any exception is to fail the test.

I'm not sure why you'd need this in tests. Your test methods should just declare "throws Exception", which alleviates the need for a try/catch/propagate.

Because it's not in the test method itself, it is in the implementation of an interface/superclass, not declaring such checked exceptions, that is only used by test methods.

 

* Checked exceptions that are extremely unlikely to ever be thrown, such as an IOException from reading an InputStream backed by a static buffer,  WrappingExecutorService.wrapTask(Runnable), or doing reflection on classes with known content.

You should never be passing a known checked exception to Throwables.propagate (we saw this pattern inside of google as well). If you want to propagate a known checked exception, just "throw new RuntimeException(checkedException)".

"throw propagate(e);" is a much more succinct and human-parseable way to convey the desired behavior. There is nothing wrong with it, other than the fact that it led to getting the rug pulled out from under us.
 

[Chris Povirk]

I cleaned up our internal docs about the deprecation and published them here:

https://github.com/google/guava/wiki/Why-we-deprecated-Throwables.propagate

[Justin Sampson]

I can actually add more problems to the list. Throwables.propagate (and friends) don't properly reassert thread interrupt status if the wrapped exception is InterruptedException, and they make it easy to accidentally wrap things we don't want to. We fixed such a bug in Monitor several years ago:

 

https://github.com/google/guava/commit/287bc67cac97052b13cbbc0358aed8054b14bd4a

 

The deprecation is painful, and I would encourage the Guava maintainers to take their time in actually removing these methods. But I do think it's the right thing long-term. I'm actually surprised that they're only deprecating propagate() and not the other methods of Throwables, because I think they're all problematic and I haven't used any of them since encountering that bug in Monitor.

 

Guava folks, please do take a look at my IOExceptions.areImpossibleIn() example earlier in this thread. A handful of such methods might alleviate many of the use cases people are concerned about and do so both safely and conveniently.

 

Cheers,

Justin

 

 

From: "guava-...@googlegroups.com" <guava-...@googlegroups.com> on behalf of Emanuel Bulic <emanue...@gmail.com>
Date: Friday, January 20, 2017 at 1:36 PM
To: Chris Povirk <cpo...@google.com>
Cc: "jgm...@gmail.com" <jgm...@gmail.com>, "guava-...@googlegroups.com" <guava-...@googlegroups.com>, "theco...@googlemail.com" <theco...@googlemail.com>
Subject: Re: [guava] Re: Throwables.propagate being deprecated?

 

Those are all excellent points, however

 

1. All these arguments should have influenced Guava long ago. It's too late now

2. Removing it will prevent engineers from adopting the new versions of the library with a simple version change.

3. It doesn't matter that people abuse it. People abuse lots of things. They probably abuse Guava collections too. What about Mutable vs Immutable objects. Let's get rid of all mutable objects because they're not thread-safe.

4. It's throwing the baby out with the bath water.

 

And most importantly I don't think it follows this very important Google principle:

Focus on the user and all else will follow.

Since the beginning, we’ve focused on providing the best user experience possible. Whether we’re designing a new Internet browser or a new tweak to the look of the homepage, we take great care to ensure that they will ultimately serve you, rather than our own internal goal or bottom line. Our homepage interface is clear and simple, and pages load instantly. Placement in search results is never sold to anyone, and advertising is not only clearly marked as such, it offers relevant content and is not distracting. And when we build new tools and applications, we believe they should work so well you don’t have to consider how they might have been designed differently.

 

Guava should follow the deprecation model of the JDK, which keeps everything around for a very long time.

 

 

On Fri, Jan 20, 2017 at 3:10 PM, Chris Povirk <cpo...@google.com> wrote:

I cleaned up our internal docs about the deprecation and published them here:

https://github.com/google/guava/wiki/Why-we-deprecated-Throwables.propagate

 

--

guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to guava-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/CAHQwt7qGMdf4BQQ308%2BWc4zL7wM%2BzG0gt%2BOPGH_tYSK6q%3DKhbQ%40mail.gmail.com.

[Chris Povirk]

How could I forget that one? :) I added a link from the multicatch section. Thanks.

For the IOExceptions.areImpossibleIn() example, your best bet is to file an issue. I don't know how likely it is that we'll get to it soon, but at least it will be in with our other feature requests. (I suspect that the try-catch is "good enough," given that we don't generally push for test coverage of impossible conditions. But if you want a glimmer of hope: We've been experimenting a bit with lambdas and exceptions lately, so maybe you'll spur someone to take a look at your idea or a spinoff.)

[Kurt Alfred Kluever]

Well we've committed to keeping Throwables.propagate() around at least until July 2018 (2 years from when we deprecated it --- although maybe not 2 years from the release that deprecated it?), but we may consider pushing that date even further.

On Fri, Jan 20, 2017 at 5:10 PM, Emanuel Bulic <emanue...@gmail.com> wrote:

Would it reasonable to ask that it be kept for all versions that support JDK8, and remove it in the first Gauva version built for JDK9? JDK upgrades take a lot of work anyway - that would a better time to get rid of it.  If that was the plan to begin with, that this is no big deal.

--

To unsubscribe from this group and stop receiving emails from it, send an email to guava-discuss+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/CAHQwt7qGMdf4BQQ308%2BWc4zL7wM%2BzG0gt%2BOPGH_tYSK6q%3DKhbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to guava-discuss+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/CAHQwt7pZ1QtOgOJV2Ra%2BDKbB%3DxVXXbepwt-mNoc1SnvHDXWNEQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

kak

[Chris Povirk]

Guava compatibility has come up in a couple different conversations at Google lately -- specifically, tools and policies to make deprecations easier on users. It's too early to say how it will all shake out, but it's possible that we'd consider, say, batching breaking changes together to make them less frequent. 

For this particular case, your best bet is probably to introduce your own MoreThrowables class with an equivalent propagate() method. Or maybe your company policy requires that you still add tests when you replace "Throwables.propagate" with "MoreThrowables.propagate?"

[Catherine Berry]

I think the idea is that, as Chris pointed out at length, we see the net value of Throwables.propagate (or any local version of it) as being negative. The various inline alternatives are almost always better, and in the small residue of cases, writing out the handling logic isn't that onerous. So rather than a thousand MoreThrowables classes scattered through the world, the hope is for a hundred thousand small improvements in Java practice.

On Fri, Jan 20, 2017 at 2:46 PM, Emanuel Bulic <emanue...@gmail.com> wrote:

Why would we, collectively, make a change that move the propagate method from Guava and into many little classes like this: com.<companyname>.guava...MoreThrowables?

Let's consider the final outcome of doing this.  Guava no longer has this one method, but, instead, we will have MoreThrowables classes all over the place with all sorts of hacks in them. That will make things worse.

On another note, can you share any statistics regarding the misuse of this method?  I understand that misuse is relative, but if you have some objective evidence that would be great.

On Fri, Jan 20, 2017 at 5:19 PM, Chris Povirk <cpo...@google.com> wrote:

Guava compatibility has come up in a couple different conversations at Google lately -- specifically, tools and policies to make deprecations easier on users. It's too early to say how it will all shake out, but it's possible that we'd consider, say, batching breaking changes together to make them less frequent. 

For this particular case, your best bet is probably to introduce your own MoreThrowables class with an equivalent propagate() method. Or maybe your company policy requires that you still add tests when you replace "Throwables.propagate" with "MoreThrowables.propagate?"

--
guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to guava-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/CAHQwt7ptEdkhbAxZwZH7Xi4eqOX8gt_nJMBJJ9m-9OtOn85o%3DA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

"Easy things should be easy, and hard things should be possible." - Larry Wall
Catherine Berry (go/cberry-name)
Software Engineer
Google Los Angeles

[Kevin Bourrillion]

Emanuel,

Here is the thing about putting users first:

It still requires someone to apply their best subjective judgment to try to make a good decision about what the user's best interest is, and there will always be some users who don't agree with that judgment. That's just reality. Your providing information helps us make it a better informed judgment, which is appreciated. But you're going further than that, to assert that our judgment must be wrong because it's not the way you see it. That part isn't helpful.

Also, going back to the part where you said, "All these arguments should have influenced Guava long ago. It's too late now."  This is really just a misunderstanding of what Guava is and the way it operates (and has always operated). We do not withhold adding things to Guava until we are willing to commit to them permanently. If we did, Guava would be much smaller and less useful than it is. It would be hard to add anything to it. 

Being able to adapt Guava based on what we learn over time is fundamentally a good thing, and knowing that we can do that makes it a lot easier for us to move forward with ideas in the first place.

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/CANTNG2Ao%3DWrHV5j0QmhM040hA-jOMYHjuwbFaqJbW%2BSCCLo2sQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

[aman...@gmail.com]

Hello,

First I want to thank the Guava team for their work and the time they spent to really think this issue before deprecating Throwables.propagate().

When I realize Throwables.propagate() was deprecated I felt frustrated. Indeed the javadoc kind of sounds like "this method may have been useful to you, but now instead of one line of code, you should write two: Throwables.throwIfUnchecked() and throw new RuntimeException(e)".

I had to read this whole thread to understand why this API was deprecated and more importantly how I should refactor my code to avoid having to write the 2 lines of code hinted in the deprecation documentation.

To avoid people who may just refactor Throwables.propagate() to Throwables.throwIfUnchecked() and throw new RuntimeException(e), would it be possible to update the documentation with an example?

For example something like:

Before deprecation

try {
  return readingFile();
} catch(Exception e) {
  throw Throwables.propagate(e);
}

After deprecation

try {
  return readingFile();
} catch(IOException e) {
  throw new RuntimeException(e);
}

Aurélien

On Saturday, January 21, 2017 at 12:16:06 AM UTC+1, Kevin Bourrillion wrote:

Emanuel,

Here is the thing about putting users first:

It still requires someone to apply their best subjective judgment to try to make a good decision about what the user's best interest is, and there will always be some users who don't agree with that judgment. That's just reality. Your providing information helps us make it a better informed judgment, which is appreciated. But you're going further than that, to assert that our judgment must be wrong because it's not the way you see it. That part isn't helpful.

Also, going back to the part where you said, "All these arguments should have influenced Guava long ago. It's too late now."  This is really just a misunderstanding of what Guava is and the way it operates (and has always operated). We do not withhold adding things to Guava until we are willing to commit to them permanently. If we did, Guava would be much smaller and less useful than it is. It would be hard to add anything to it. 

Being able to adapt Guava based on what we learn over time is fundamentally a good thing, and knowing that we can do that makes it a lot easier for us to move forward with ideas in the first place.

On Fri, Jan 20, 2017 at 2:59 PM, 'Catherine Berry' via guava-discuss <guava-...@googlegroups.com> wrote:

I think the idea is that, as Chris pointed out at length, we see the net value of Throwables.propagate (or any local version of it) as being negative. The various inline alternatives are almost always better, and in the small residue of cases, writing out the handling logic isn't that onerous. So rather than a thousand MoreThrowables classes scattered through the world, the hope is for a hundred thousand small improvements in Java practice.

On Fri, Jan 20, 2017 at 2:46 PM, Emanuel Bulic <emanue...@gmail.com> wrote:

Why would we, collectively, make a change that move the propagate method from Guava and into many little classes like this: com.<companyname>.guava...MoreThrowables?

Let's consider the final outcome of doing this.  Guava no longer has this one method, but, instead, we will have MoreThrowables classes all over the place with all sorts of hacks in them. That will make things worse.

On another note, can you share any statistics regarding the misuse of this method?  I understand that misuse is relative, but if you have some objective evidence that would be great.

On Fri, Jan 20, 2017 at 5:19 PM, Chris Povirk <cpo...@google.com> wrote:

Guava compatibility has come up in a couple different conversations at Google lately -- specifically, tools and policies to make deprecations easier on users. It's too early to say how it will all shake out, but it's possible that we'd consider, say, batching breaking changes together to make them less frequent. 

For this particular case, your best bet is probably to introduce your own MoreThrowables class with an equivalent propagate() method. Or maybe your company policy requires that you still add tests when you replace "Throwables.propagate" with "MoreThrowables.propagate?"

--
guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to guava-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/CAHQwt7ptEdkhbAxZwZH7Xi4eqOX8gt_nJMBJJ9m-9OtOn85o%3DA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

"Easy things should be easy, and hard things should be possible." - Larry Wall
Catherine Berry (go/cberry-name)
Software Engineer
Google Los Angeles

--
guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to guava-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/CANTNG2Ao%3DWrHV5j0QmhM040hA-jOMYHjuwbFaqJbW%2BSCCLo2sQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Stephan Schroevers]

Hi Aurélien,

The documentation was updated with a link to a number of examples in https://github.com/google/guava/commit/829613401de295d6c6be65ff08d67d02cbbdf5ab. So that should do.

But the particular example that you pointed out does make me wonder: perhaps better tooling can help us here as well. I filed https://github.com/google/error-prone/issues/517.

Cheers,
Stephan

[Aurélien Manteaux]

Hi Stephan,

Thank you for the documentation, that is exactly what I was looking for!

Indeed that would be great if error prone could point out that a generic exception is caught instead of a specific one.

Cheers,

Aurélien

[Chris Povirk]

On another note, can you share any statistics regarding the misuse of this method?  I understand that misuse is relative, but if you have some objective evidence that would be great.

I think the only numbers I have are:

75% who pass a known checked or known unchecked exception[1][2]

5% who are rethrowing ExecutionException.getCause()[3]

1% who are forced to write dummy throws/return statements[4]

As for the others: It's of course hard to put a number on "obscures in general." I don't have a trivial way to search for the specific pattern I mentioned (catching one exception and then propagating another), nor to search for most of the other patterns. I can say that most of them are pretty rare -- e.g., ~2 total instances of another problem I just added.

[1] I don't have numbers for the breakdown between the two. I think that known checked was the majority but not the overwhelming majority. For known unchecked, I blame Eclipse, which IIRC used to generate catch() blocks for any exception with @throws documentation when you asked for a try-catch.

[2] Some of the known unchecked exceptions could have removed the try-catch entirely. I don't have numbers for this.

[3] Which, to be fair, could be legitimate in cases like a thread-confined LoadingCache, but that's probably a small fraction.

[4] That's 1% other than the 80% we've already counted. Some of the 80% had to do this, as well, so it's probably closer to 2% overall.

[Chris Povirk]

Internally, the amortized cost for removing one call was probably a couple seconds, so if we can save a few people a few hours each, we're pretty happy with the result. Externally, yeah, things are messier, and people may be better off introducing a MoreThrowables.propagate() to make the migration fast there, too.

[Emanuel Bulic]

Obviously, I'm not very concerned with what it costs Google to make the migration.

[Pat Farrell]

On Mon, Jan 23, 2017 at 3:05 PM, Emanuel Bulic <emanue...@gmail.com> wrote:

On Mon, Jan 23, 2017 at 2:38 PM, Chris Povirk <cpo...@google.com> wrote:

Internally, the amortized cost for removing one call was probably a couple seconds, so if we can save a few people a few hours each, we're pretty happy with the result.

 

Obviously, I'm not very concerned with what it costs Google to make the migration.

I can see with both views on this. I've been a user since Guava was just called Collections. I am sure that Google's internal use of it over the many years swamps most of us external users. And Google is famous for developing serious tools to do code inspections across multiple code bases, automating changes, regression testing, etc. that we mere mortals can only dream of.

Sadly, as long as Google provides most of the engineering manpower to develop Guava, makes most of the commits, and uses it the most, they kinda have the gold in a world where the guy with the gold rules.

I'm glad that they listen to us mortals. I don't expect them to act on everything they hear.

In general, I like when stuff is deprecated. Long upthread, someone mentioned Java's Date class, which should have been deprecated at the turn of the century. 

Pat