Is returning null after exception is caught bad design

I would say don't catch the exception if you really can't handle it. And logging isn't considered handling an error. Better to bubble it up to someone who can by throwing the exception.

If you must return a value, and null is the only sensible thing, there's nothing wrong with that. Just document it and make it clear to users what ought to be done. Have a unit test that shows the exception being thrown so developers coming after you can see what the accepted idiom needs to be. It'll also test to make sure that your code throws the exception when it should.

I always come across the same problem that when an exception is caught in a function that has a non-void return value I don't know what to return.

If you don't know what to return, then it means that you don't know how to handle the exception. In that case, re-throw it. Please, don't swallow it silently. And please, don't return null, you don't want to force the caller of the code to write:

Foo foo = bar.getFoo();
if (foo != null) {
    // do something with foo
} 

This is IMHO a bad design, I personally hate having to write null-checks (many times, null is used where an exception should be thrown instead).

So, as I said, add a throws clause to the method and either totally remote the try/catch block or keep the try/catch if it makes sense (for example if you need to deal with several exceptions) and rethrow the exception as is or wrap it in a custom exception.

Related questions

• How to avoid “!= null” statements in Java?