...
The openPasswordFile method controls access to the sensitive password file and returns its reference. Since Because it cannot control being invoked by untrusted user methods, it should not assert its privileges within the body. Instead, changePassword() the caller method, can safely assert its own privilege whenever someone else calls it. This is because changePassword() does not return a reference to the sensitive file to any caller but processes the file internally. Also, since because the name of the password file is hard-coded in the code, caller supplied (tainted) inputs are not used. Also, notice that the methods have been declared private in this case to limit scope.
...
Note that the above compliant solution prints a general Error error instead of revealing sensitive information (See EXC01-J. Do not allow exceptions to transmit sensitive information). If no sensitive information can be potentially revealed by any of the possible exceptions, an equivalent mechanism that allows exceptions to be wrapped can be used. For example, if an applet doesn't have access to read system files that contain fonts, it can accomplish the task from a privileged block without revealing any sensitive information. In fact, by not swallowing exceptions, the client will be able to deduce the symptoms of a read failure easily. In summary, if the code can throw a checked exception safely, use the form of doPrivileged method that takes a PrivilegedExceptionAction instead of a PrivilegedAction.
...