50

There is a method get(sql) (I can not modify it). This method returns MyObjects and it has to be in try catch block because JqlParseException is possible there. My code is:

String sql = something;
try{
   MyObject object = get(sql);
} catch(JqlParseException e){
   e.printStackTrace();
} catch(RuntimeException e){
   e.printStackTrace();
}

I want to remove try catch and use Optional class, I tried:

MyObject object = Optional.ofNullable(get(sql)).orElseThrow(RuntimeException::new);

but IDE force there try catch too. And for:

MyObject object = Optional.ofNullable(get(sql)).orElseThrow(JqlParseException::new));

is an error (in IDE) The type JqlParseException does not define JqlParseException() that is applicable. Is there any way to avoid try catch blocks and use optional?

joe paulens
  • 601
  • 2
  • 7
  • 9
  • 1
    Jump to the definition of `get`, see if it says `throws JqlException`. If it does, you must use try...catch. – Sweeper Mar 24 '17 at 07:13
  • 4
    It seems that quite a lot of people are considering Optional as the NextGeneration™ control flow construct. That's not going to happen. Optional, as well as its primitive counterparts, inherently can't handle this kind of task. It's not designed to completely replace control flow constructs like if-else or try-catch. Instead, it focuses on getting rid of those endless null checks. – glee8e Mar 24 '17 at 07:31
  • @glee8e *[`Optional`] focuses on getting rid of those endless null checks.* I'd be more specific. Many people would jump to the conclusion that they ought to replace all occurrences of `null` with `Optional`, which goes against the intent of `Optional`'s designers. – jub0bs Mar 24 '17 at 09:12
  • @Jubobs Maybe I'm still not senior enough to know where `null` can't be replaced with `Optional`, except in performance critical code or there is a design flaw. Please point out a situation, except those listed above, where `null` is used but `Optional` is not applicable. – glee8e Mar 25 '17 at 11:47
  • 1
    @glee8e You shouldn't use `Optional` fields or parameters. [As Brian Goetz puts it](http://stackoverflow.com/a/26328555/2541573), *[their] intention was to provide a limited mechanism for library method return types where there needed to be a clear way to represent "no result", and using `null` for such was overwhelmingly likely to cause errors*. See also [this great talk by Stuart Marks](https://www.youtube.com/watch?v=Ej0sss6cq14). – jub0bs Mar 27 '17 at 20:28
  • @Jubobs Well, such weird usage of Optional never occurred to me. Thanks to point out another weird mistake people may make. – glee8e Mar 28 '17 at 11:35
  • @glee8e Regarding “next generation”: Optional values have been used in ML-like languages for decades. But ML-like languages have algebraic data types and pattern matching which makes using values-as-errors more ergonomic. – Guildenstern Jul 09 '20 at 10:11

5 Answers5

96

Optional is not intended for the purpose of dealing with exceptions, it was intended to deal with potential nulls without breaking the flow of your program. For example:

 myOptional.map(Integer::parseInt).orElseThrow(() -> new RuntimeException("No data!");

This will automatically skip the map step if the optional was empty and go right to the throw step -- a nice unbroken program flow.

When you write:

 myOptionalValue.orElseThrow(() -> new RuntimeException("Unavailable"));

... what you are really saying is: Return my optional value, but throw an exception if it is not available.

What you seem to want is a way to create an optional (that instantly catches the exception) and will rethrow that exception when you try using the optional.

john16384
  • 7,800
  • 2
  • 30
  • 44
  • how can we also attach the HttpStatus code with the exception in this example ? – humbleCodes Apr 04 '23 at 16:54
  • @humbleCodes you can just throw a `HttpStatusCodeException` or `ResponseStatusException`, it will depend on the framework and what exceptions are available for this purpose. You can also define your own exception that accepts a status code. – john16384 Apr 04 '23 at 20:38
  • do you know any resources which have used implementations for Spring/Spring Boot framework applications ? – humbleCodes Apr 05 '23 at 15:12
13

That's not how Optionals work. They don't make try-catch-blocks obsolete. However, you could introduce a new wrapper-function like this:

public Optional<MyObject> getMyObject(final String jql) {
    try {
        return Optional.ofNullable(get(sql));
    } catch (final JqlParseException e) {
        return Optional.empty();
    }
}

You won't have to deal with the exception anymore, but you won't know if there was an error if you get an empty Optional as well.

stevecross
  • 5,588
  • 7
  • 47
  • 85
2

Try this

Optional.ofNullable(result)
                .orElseThrow(() -> new GenericClientException("Request body is not valid", HttpStatus.BAD_REQUEST));
naveen
  • 21
  • 3
0

if (StringUtils.isEmpty(message)) {

            throw new ValidationException("empty message body received from the queue");

in java 8

Optional.ofNullable(message).filter(message -> !message.isEmpty()).orElseThrow(() -> new ValidationException("empty message body received from the queue")

        );
            
0

Optional helps to deal with NullPointerException.

You can use it to cast new exceptions as mentioned.

MyObject object = Optional.ofNullable(get(sql)).orElseThrow(RuntimeException::new);

However, your method get(sql) is not returning NULL, which invalidates the use of OPTIONAL as desired.

I would keep using Try Catch.