0

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);
    }
}
}
}
  • what programming language is your code snippet written in? – gnat Feb 3 '15 at 16:56
  • C#... probably should've mentioned that... – MegaMark Feb 3 '15 at 17:04
  • 1
    why do you use the word "sadly" for not rethrowing the exception? – gansub Feb 3 '15 at 17:19
4

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.

  • Accepted. I should've also mentioned that System1 prints a message to the end user in the form of 'something went wrong with what you were doing...' Although there is no need for the system1 user to know the details of the error, they still need to know there was an error. System2 returns a string and in the event of an error, returns it formatted as 'Result: error; ...' In system1, the catch block never will be hit because System2 will ALWAYS return the expected type String. Which leaves me with the ugly result of using a regex to check the return string; if match, throw new exception("ERR"); – MegaMark Feb 3 '15 at 21:04
1

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.

  • But how then do you go about catching it (the exception) in system1... – MegaMark Feb 3 '15 at 17:26
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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