Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have the following :

public class doCheck(){

    public void performCheck(){
        try {
            perform all checks......
        }
        catch(Exception e){
            logger.error("Exception occured in class doCheck in method performCheck");
            thrown new MyNewException(e.getMessage());
        }
    }
}

Is it safe to log the class and method name?

share|improve this question

migrated from codereview.stackexchange.com Jun 27 '12 at 2:29

This question came from our site for peer programmer code reviews.

3 Answers 3

up vote 8 down vote accepted

That depends on whether your code base is hidden or not. If you ship the product to the client then he can inspect the Java byte code trivially anyway, so logging class names doesn’t reveal any information the user cannot get anyway.

For a server-side application, this is still true. However, it may be a security hole to display such logs to the client. That’s why most web application frameworks distinguish between a development and production configuration: during development, debug information is displayed to the user in the case of an error. In production, this information is logged on the server, but no longer displayed in the web browser / to the client.

share|improve this answer
    
Yes, and it is important to insure that the logs themselves are secure - can't be accessed by external users and absolutely cannot be modified. –  Donald.McLean Jun 26 '12 at 12:52
2  
In summary, logging the class/method is a good thing. Allowing the log (or a stacktrace) to escape is a bad thing. –  Qwerky Jun 27 '12 at 11:57

@Konrad answered the direct question, however your exception handling has one minor and two serious problems. Since you originally posted to codereview.SE, here they are:

  1. Logging an exception before throwing is pointless. Log it where you handle it, and don't bother catching it if you don't plan to handle ti.
  2. If you're going to log an exception, log the exception; don't simply say "an exception happened" and expect people to guess what the exception is. All common logging frameworks provide a two-argument method: the first is the message, the second is the throwable.
  3. Rethrowing an exception with just a message is the same problem but a worse instance. I can understand (barely) why you might not want an exception stack trace to show up in your logs. But once you throw the new exception, you have absolutely no way to tell what the real problem is. Especially if you keep up the habit of catching and rethrowing.

OK, I'm going to add a fourth issue: you log where the exception happened, but you don't say what you were doing when it happened, or give any contextual information. If you log the actual exception (point #1), you'll know where it happened. More important is saying something like "unable to open file foo.txt".

share|improve this answer

It's not particularly unsafe, so unless there's anything critical that you'd want to hide in this class or if the class is part of a critical path (like a secure handshake or "hidden" feature), I wouldn't consider this an issue at all.

Furthermore, we're talking about Java here. So if we're talking about a client-side app running Java on the client, they can always modify their JRE to use add their own debugging routines and/or use a custom classloader and access your classes pretty much any way they want to. Making it harder for them (by way of hiding stuff deeper, or even obfuscating code) is always a possibility, but it usually isn't cost-effective when you consider the time and effort needed to achieve this against the loss caused by statistically improbable malicious users.

If we're talking about a server-side piece of software that may output logs to clients (say, to the user's browser), then it probably isn't too big a deal, but it's already more straightforward to fix: configure your container accordingly, and use a logging framework or multiplexer to output to appropriate files on the server for debugging purposes instead. This way you retain useful records for debugging but don't compromise potentially useful information.

But in general, this probably wouldn't be a problem. it's more what you put in the debug message that could be an issue, as we often tend as developers to output things we work on (you don't want to leave these debug outputs for usernames, passwords, salts and security tokens in clear view).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.