Convention for logging within nested try catch blocks

Question

I've looked at this question but it doesn't really help solve my dilemma.

System 1 calls system 2 within a try catch, the method in system 2 has it's own try catch, which sadly handles an exception but does not re-throw it. So my question is: Which system should log it? Each system has it's own logging files.

Sample:

Class System1{
Public void DoSomething(){
    Try{
        var sys = new System2();
        sys.ExecuteMethod();
    }
    Catch{Exception e){
        logger.log(e);
    }
}
}
// ------IN A DIFFERENT SYSTEM ON A DIFFERENT MACHINE------
Class System2{
Public void ExecuteMethod(){
    Try{
        throw new Exception("Test Excpetion");
    }
    Catch{Exception e){
        logger.log(e);
    }
}
}
}

Answer 1

If the system 2 handles the exception and doesn't rethrow it, then it sounds like system 1 doesn't have any way of knowing that an exception occurred. In that case, there's really no question as to whether system 1 should log anything, since it doesn't know an error occurred!

If both systems are aware of the error, and they are logging to different places, and the error is something you want logged, then you probably should have both of them log the error. You might want to think about finding a way to unify the logging though, as multiple log files are a pain to sift through (unless this is a client/server system where system 2 is running on a different machine than system 1, then you want to log in both places).

If system 2 is legitimately handling the error, then there is probably no need to log it in system 1. There might not even be a reason to log it in system 2 either, but you need to analyze whether that is required for your situation.

I would generally recommend that when in doubt, log it. But you definitely want to check at some point whether you are logging too much information, preferably before going to production.

Answer 2

You could argue that they should both log it.

System 1 is trying to accomplish something but needs to access System 2. System 1 should log that it couldn't successfully complete its work for some reason or another due to its dependency on System 2. If System 2 encounters an internal error processing a request, it should be logging those types of issues as well.

Other use cases do arise, including authorization, network connectivity, malformed requests, etc. Consider each one and how each system should (if required) log that.

Answer 3

It depends on the exception. If you expect that the exception may occur and it is valid, and you are actually handling it, as in, you've got plan B for that situation, then don't throw it.

If the exception breaks the workflow and you aren't actually handling it, go ahead and log it if you deem it necessary, but sometimes the current method scope doesn't have enough useful information to justify logging it. Sometimes you'll want to throw it to a higher scope with more useful information, catch it there, then log it.

For example:

int DoSomething1(int userId, int transactionId) {
    try {
        int orgId = GetOrgId(userId);
        DoSomething2(orgId);
        /* ... more things ... */
    } catch(MyException ex) {
        Log(string.Format("{0}\nuser: {1}, trns: {2}\n\tMessage: {3}\n\t\tTrace: {4}", 
            ex.Message, userId, transactionId, ex.InnerException.Message, ex.InnerException.StackTrace));
        throw;
    } catch(Exception ex) {
        Log(string.Format("user: {0}, trns: {1}\n\tMessage: {2}\n\t\tTrace: {3}", 
            userId, transactionId, ex.Message, ex.StackTrace));
        throw;
    }
}

int DoSomething2(int orgId) {
    try {
        /* ... some stuff .... */
    } catch(Exception ex) {
        throw new MyException { Message = string.Format("org: {0}", orgId),
            InnerException = ex };
    }
}

Your front-end shouldn't dump stack traces to users, so if the exception gets that far, you have to handle it one way or another. But then that depends on what the front-end is. If its a webservice, error codes are very nice instead of deceptively pretending that everything went swimmingly, or giving them no feedback at all.