0

Writing in Java. This is a problem that is befuddling me, and it also feels right out of my grasp. Here is a little pseudo-code in a try block and real code in the catch block.

try {

    // 83 lines of code that do a bunch of stuff, with methods that call other
    // methods which call which call other methods

} catch (Exception e) {
    logger.writeLogError("*********FAILURE BEGIN*********\n");
    e.printStackTrace();
    logger.writeLogError("*********FAILURE END*********\n");
    String errorMesg;

    // Any downstream method that throws an exception without a message
    // will have e.getMessage == null
    if(e.getMessage() == null) {
        // This is for an unanticipated exception.  
        // The stack trace should give more information.
        errorMesg = "Skipped.  Unknown exception.  Check logs for string Exception thrown: ";
    } else {
        errorMesg = "Skipped. " + e.getMessage();
    }
}

The variable "errorMesg" is written to a database table. It is not printed to the log. So here's the problem. Something is happening somewhere deep in the bowels of the code that is throwing a NullPointerException. This is what we see in the log file.

2022-10-25 14:06:28,583 ERROR [com.fdc.gibson.services.orderentry.ThisClass] (WorkerThread#39[192.168.136.172:55767]) ********FAILURE BEGIN********

2022-10-25 14:06:28,584 ERROR [STDERR] (WorkerThread#39[192.168.136.172:55767]) java.lang.NullPointerException
2022-10-25 14:06:28,584 ERROR [com.orderentry.ThisClass] (WorkerThread#39[192.168.136.172:55767]) ********FAILURE END********

I cannot figure out why the information from the stack trace is so sparse. My guess is that there's a suppressed exception deep down and that just adding a call to e.getSuppressed() will ferret this out. I'm not sure. But why is the stack trace being swallowed? Maybe it's something obvious that I am missing. I'm sure we are doing some really stupid things here, but I didn't write most of this code and I am trying to un-stupid it.

mstabosz
  • 55
  • 2
  • 9
  • 2
    under various circumstances, the jvm stops generating stacktraces. This might happen in that Exception is thrown all the time, so the JVM tries to save resources by not creating stacktraces anymore after X occurrences. Can you restart your jvm and verify this? – f1sh Mar 24 '23 at 15:42
  • 3
    Does this answer your question? [When does JVM start to omit stack traces?](https://stackoverflow.com/questions/58696093/when-does-jvm-start-to-omit-stack-traces) – f1sh Mar 24 '23 at 15:42
  • suppressed exceptions are unrelated to what you are describing. A suppressed exception is an exception that occurs during the processing of an exception and which is virtually guaranteed to be describing the same general problem, but with a stack trace that is strictly less useful. Suppressed exceptions don't lose their traces any sooner, nor does the addition of a suppressed exception cause the exception they are added to to lose its stack trace. The explanation is highly likely what 2 comments above this one are leading you to. – rzwitserloot Mar 24 '23 at 15:55
  • Hi folks. Sorry I did not follow up last week. I was on vacation and pretty thoroughly tuned work out. f1sh, I followed the link you provided, and it says "Also,As per this, passing -XX:-OmitStackTraceInFastThrow will make sure my StackTrace is not lost." I'm a little confused on how to do that though. – mstabosz Apr 03 '23 at 16:58
  • Hi thanks for the comments guys. I kind of gave up on trying to figure out exactly what was throwing the NullPointerException. It was pretty rare. I said "we are never going to figure out where this is coming from", and I suggested we at least mitigate this by refactoring some of the code in the try-catch block into methods with their own try-catch blocks. It would at least narrow down where this was happening in the future. That idea was shot down. It's not my responsibility to fix this; so I just gave up. No biggie. – mstabosz Jun 05 '23 at 14:57

0 Answers0