Question: In a `switch` statement there are a few cases where I need to parse user input in the form a string into a Date object. I'm using `java.text.SimpleDateFormat`, but instead of instantiating and calling `parse` for each case, I'd like to encapsulate the date parsing in something of a utility method. It's important that the parse method have exception handling in the event the user inputs a string that doesn't match the pattern passed to the `SimpleDateFormat`.

The problem I'm running into and run into a lot with java is where to place the `return` statement. This is what I have tried:

```
public class MainMenu {

    // a bunch of other stuff

    public static Date parseStrDate(String dateStr) throws ParseException {
        String pattern = "yyyy/mm/dd";
        SimpleDateFormat dateParser = new SimpleDateFormat(pattern);
        try {
            Date date = dateParser.parse(dateStr); 
        }
        catch (ParseException e) {
            System.out.println(e);
        }
        return date; 
    }
}

```

Implemented this way, the compiler complains that `date` is not defined, since it's only defined in the try subcontext. If I try to return from the `try` context and remove the final `return date;`, the compile complains that it's expecting the `return` statement promised in the method declaration. I've also tried first defining `date` in the scope of the method just below `pattern` expecting it to only be redefined in the `try` statement. No-go there either, though. Beginning to feel like the entire utility method might not be the route to take. Any opinions on how to implement this?

Answer: 
This largely depends on what type you're returning, and what the `Exception` *means* in terms of your method's flow.

For example, in the following case, sending a notification of the result has failed, but you can still return the result:

```java
private final Notifier notifier;

public String getResult() {
    final String result = "meow";

    try {
        this.notifier.notifyOf(result);
    } catch (final IOException ioEx) {
        System.out.println("Couldn't notify");
    }

    return result;
}

```

---

In other circumstances, you could return some information about what had happened. For example, let's say your return type is some `Response` object, which has an `isError` flag on it, then you could do the following:

```java
public Response getResponse(final Request request) {
    try {
        return this.process(request);
    } catch (final Exception ex) {
        return Response.forError().withMessage("Couldn't process");
    }
}

```

In the case of the method you've posted about, I would argue that there isn't a sensible response you can give for an un-parseable `String` (there's no default 'date' in most contexts). So for me, the handling would be something like:

```java
public Date parseDateStr(final String input) {
    try {
        return this.dateParser.parse(input);
    } catch (final ParseException pEx) {
        throw new IllegalArgumentException("Couldn't parse date-string: " + input);
    }
}

```

---

Other times, just propagating the `Exception` back to whatever called the method is the appropriate thing to do. It really depends on the context, and whether there is something sensible you can return or do in the case of that specific `Exception`.

---

As the other answer mentions though, you can get around this compiler warning by declaring (and initialising to some default) the return value outside of the `try` block: but that's not necessarily the best thing to do unless there's some sensible 'default' you can give.
```
class MainMenu {
    // a bunch of other stuff

    public static Date parseStrDate (String dateStr) {
        String pattern = "yyyy/mm/dd";
        SimpleDateFormat dateParser = new SimpleDateFormat (pattern);
        Date date = new Date (0L);
        try {
            date = dateParser.parse (dateStr);
        } catch (ParseException e) {
            System.out.println (e);
        }
        return date;
    }
}

```

Define `date` outside of the `try`. Initialize it with a nonsense date or perhaps `null`. Parse as before.

Removed the `throws` because it does not `throw` because it `catch`es.