I prefer at the very end.  Only if the logic of the method is very
simple is it ok to embed a return in the body of a method.  Or if
embedding the return simplifies the logic.

The reason here is just to make it simple to read.  The compiler is
allowed to rearrange things to make them more efficient.  Trust it to do
its job.

Move it back to the try{} block.  Add the "throw e;" that I had in to
the catch{} block.  See if that helps.

The compiler complained because there must be a reachable return. If you
stick your return in the try block and there's an exception beforehand you
won't have a return. There doesn't need to be a return statement in the
outermost scope, no, not if all the possible execution paths have a return
in them. Try an if-else and put returns in there, and not in the outermost
scope of the method - it will compile.

With try blocks, bear in mind that a return in a try won't, not if you have
a finally clause also. And don't use return in a finally clause...although
you can. Mind you, you'll get warned about the latter.

You can have (legally) a return in the try block, and the compiler won't
complain, not if there is no code prior that will throw an exception.

Having said all that, what's best practise, exceptions or not? Many people
will say that multiple return statements in a method are bad, others strive
for a single return statement (which under normal circumstances but not
always) would be in outermost method scope but occasionally use multiple
returns, and others sprinkle returns everywhere. I myself would sort of go
with Bruce Eckel here:
http://onthethought.blogspot.com/2004/12/multiple-return-statements.html

AHS