Add Optional.get() method that takes an error message string

[GoogleCodeExporter]

I rarely call Optional.get() without first checking isPresent() because I want 
to provide a useful error message. For example, I end up writing this:

    public Node getCurrentNode() {
        checkState(currentNode.isPresent(), "current node does not exist");
        return currentNode.get();
    }

I would rather write this:

    public Node getCurrentNode() {
        return currentNode.get("current node does not exist");
    }

This gets annoying when it breaks chaining:

    checkState(currentNode.isPresent(), "current node does not exist");
    currentNode.get().ping();

The additional method would allow chaining:

    currentNode.get("current node does not exist").ping();

Original issue reported on code.google.com by electrum on 30 Apr 2013 at 6:20

[GoogleCodeExporter]

Original comment by kurt.kluever on 30 Apr 2013 at 6:22

• Added labels: Package-Base, Type-Addition

[GoogleCodeExporter]

Maybe naming the method checkedGet(String message) would be more clear to a 
reader.

Original comment by d...@iq80.com on 30 Apr 2013 at 6:23

[GoogleCodeExporter]

Interesting...What do you do with the exceptions/error messages? Presumably 
they get caught at a higher level and logged?  Are you concerned about 
debugging (and in that case, isn't the stack trace enough)?

Original comment by kurt.kluever on 30 Apr 2013 at 6:24

[GoogleCodeExporter]

From my POV this is a convenience method which can be used for instance to 
return a more descriptive error message to a user (instead of get called on 
absent). BTW other frameworks provide this functionality too: 
https://github.com/functionaljava/functionaljava/blob/master/core/src/main/java/
fj/data/Option.java#L183.

Original comment by hammersc...@gmail.com on 7 Feb 2014 at 12:51

[GoogleCodeExporter]

Your example is of using a fixed literal string, which conveys no additional 
information that the combination of stack trace and API docs don't already 
provide. To us, that's not enough motivation. Why bother providing these 
strings? The audience for them is an engineer who's going to have to look at 
the code regardless.

The real motivation to do this would be if you commonly have data you need to 
supply to that string, but in that case, the message construction features of 
Preconditions are useful to have anyway.

Original comment by kevinb@google.com on 10 Feb 2014 at 6:12

• Changed state: WorkingAsIntended

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<issue id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:12

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08

• Added labels: Restrict-AddIssueComment-Commit