Ah yes, code that takes code in its argument. One might like to think that things like that are exceptional cases, but that isn't necessarily so for many of the things one might want to do with Mathematica. So this sort of thing is very worth remembering when one finds behavior that seems "buggy" in code that one has written that processes code--and such cases will invariably have Hold* attributes or make use of Unevaluated and things like that....

Actually I always use

f[...] :=
    Catch@Module[{...},
        ...
        If[error, Message[f::err]; Throw[$Failed]];
        ...
        If[otherError, Message[f::err]; Throw[$Failed]];
        ...
        result
     ]

in those cases ;-) . Part of the reason is just habit, but also it allows me to control exactly where the Throw gets caught without any ambiguity. And one can use tags in appropriately palced Throws and Catches if a more complex logic is needed.

And a more general statement is never to use Return anywhere in your Mathematica programs. (Nor use Label, Goto, or other ancient approaches to flow control--they are in Mathematica for those who are coming from old programming paradigms, but are strongly recommended against.) If you need to leave a program flow prematurely use Throw and Catch or in some cases Sow and Reap. Remember that Mathematica returns the last evaluation in a CompoundExpression (i.e., a sequence of commands separated by semicolons) so long as the final command is not ended with a semicolon.

Actually f2[2] returns "Return[3]". Don't use "Return" in a pure function, write

f2 := Function[{x}, x + 1];

Now f2[2] returns 3.