• SG (unregistered)

    Actually, getStackTrace doesn't work all that well with most logging frameworks, which expect you to be logging an exception if you want a stacktrace. The usual syntax therefore tends to be along the lines of log.debug(new Exception("log me")).

  • LXE (unregistered)

    Someone didn't know one could new Exception(). Otherwise fairly reasonable.

  • Lothar (unregistered)

    Fun fact: Java omits the stacktrace of a NullPointerException if they happen too often. So with this "pattern" you will sooner or later end up with log entries, that only contain the info about a NullPointerException without any stacktraces (I know that there is a system property that disables this function, but still...)

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered)

    The JVM can also skip generating the stack trace for this NullPointerException if it's executing with the -XX:-OmitStackTraceInFastThrow option (though perhaps this application isn't using that option):

    https://stackoverflow.com/questions/58696093/when-does-jvm-start-to-omit-stack-traces

  • (nodebb)

    I have written logging functions myself, but at least I took a hint with the advantages of actually encapsulating the conditional logic 😅

    What's more tricky is to use format strings and ensure that the string interpolation won't fail at runtime. In Python patterns like

    mylog(lambda: f"...")

    can help with that to get bothazy evaluationand static checking, but it suffers from the verbosity of using the full variable names in the format string. I usually find printf style format strings (like in the standard logging library) or str.format with abbreviated keyword arguments more clear, but then the static checking goes out of the window.

    Other languages may not even have a good way of checking these things.

    Of course, we don't do ourselves any favors in my at-work project with the pattern of

    call log_message('error', 'name_of_method', 5, interArray, realArray, characterArray)

    where the format string is externalized into a separate subroutine for, effectively, the sole purpose of providing a unique error code in order to not include a user-visible backtrace.

  • (nodebb)

    There's never a good answer to logging and tracing that doesn't clutter the code. But this one is a real gem of a mess.

    AOP is about the only way to do this neatly, and that's a whole 'nuther kettle of fun fish to deal with.

  • (nodebb) in reply to WTFGuy

    There's never a good answer to logging and tracing that doesn't clutter the code.

    The most annoying part is that good error messages providing useful context frequently need a lot more information than the actual logic of a routine... So logging/error messages have a tendency of breaking blackboxing of components.

Leave a comment on “A Debug Log”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article