NullPointerException ใน Java ที่ไม่มี StackTrace

ฉันเคยมีอินสแตนซ์ของรหัส Java ของเราจับได้NullPointerExceptionแต่เมื่อฉันพยายามเข้าสู่ StackTrace (ซึ่งโดยทั่วไปแล้วจะเป็นการโทรThrowable.printStackTrace() ) สิ่งที่ฉันได้รับคือ:

java.lang.NullPointerException

มีคนอื่นเจอเรื่องนี้ไหม? ฉันลอง googling สำหรับ "java null pointer empty stack trace" แต่ก็ไม่เจออะไรแบบนี้

คุณอาจใช้ HotSpot JVM (เดิมคือ Sun Microsystems ซึ่งซื้อในภายหลังโดย Oracle ซึ่งเป็นส่วนหนึ่งของ OpenJDK) ซึ่งดำเนินการเพิ่มประสิทธิภาพจำนวนมาก ในการรับร่องรอยสแต็กกลับมาคุณต้องผ่านตัวเลือก-XX:-OmitStackTraceInFastThrowไปยัง JVM

การปรับให้เหมาะสมคือเมื่อเกิดข้อยกเว้น (โดยทั่วไปคือ NullPointerException) เป็นครั้งแรกการติดตามสแต็กเต็มจะถูกพิมพ์และ JVM จะจดจำการติดตามสแต็ก (หรืออาจเป็นเพียงตำแหน่งของรหัส) เมื่อข้อยกเว้นนั้นเกิดขึ้นบ่อยครั้งเพียงพอการติดตามสแต็กจะไม่ถูกพิมพ์อีกต่อไปทั้งสองเพื่อให้ได้ประสิทธิภาพที่ดีขึ้นและไม่ทำให้บันทึกมีจำนวนสแต็กเหมือนกัน

เพื่อดูวิธีการนี้จะดำเนินการใน HotSpot JVM, คว้าสำเนาของมันOmitStackTraceInFastThrowและค้นหาตัวแปรโลก ครั้งสุดท้ายที่ฉันมองไปที่รหัส (ใน 2019) มันอยู่ในแฟ้มgraphKit.cpp

ตามที่คุณพูดถึงในความคิดเห็นคุณใช้ log4j ฉันค้นพบสถานที่ที่ฉันเขียน (โดยไม่ได้ตั้งใจ)

LOG.error(exc);

แทนแบบทั่วไป

LOG.error("Some informative message", e);

ผ่านความเกียจคร้านหรือบางทีก็ไม่ได้คิดถึงมัน ส่วนที่โชคร้ายของเรื่องนี้คือมันไม่ทำงานตามที่คุณคาดหวัง logger API ใช้วัตถุเป็นอาร์กิวเมนต์แรกไม่ใช่สตริง - จากนั้นจะเรียกไปที่ String () บนอาร์กิวเมนต์ ดังนั้นแทนที่จะได้รับการติดตามสแต็คที่ดีงามมันแค่พิมพ์ toString - ซึ่งในกรณีของ NPE นั้นค่อนข้างไร้ประโยชน์

บางทีนี่คือสิ่งที่คุณกำลังประสบอยู่?

เราเคยเห็นพฤติกรรมแบบเดียวกันนี้ในอดีต มันกลับกลายเป็นว่าด้วยเหตุผลบางอย่างที่บ้าคลั่งหาก NullPointerException เกิดขึ้นที่สถานที่เดียวกันในรหัสหลาย ๆ ครั้งหลังจากใช้ไปสักพักLog.error(String, Throwable)จะหยุดรวมถึงร่องรอยสแต็กเต็ม

ลองดูเพิ่มเติมในบันทึกของคุณ คุณอาจพบผู้กระทำผิด

แก้ไข: ข้อผิดพลาดนี้ฟังดูเกี่ยวข้อง แต่ได้รับการแก้ไขนานแล้วมันอาจไม่ใช่สาเหตุ

นี่คือคำอธิบาย: ฮอตสปอตทำให้เกิดข้อยกเว้นสูญเสียการติดตามสแต็กในการผลิต - และการแก้ไข

ฉันทดสอบบน Mac OS X แล้ว

• รุ่น java "1.6.0_26"
• สภาพแวดล้อมรันไทม์ Java (TM) SE (บิลด์ 1.6.0_26-b03-383-11A511)

• เซิร์ฟเวอร์ Java HotSpot (TM) 64- บิต VM (สร้าง 20.1-b02-383, โหมดผสม)

  Object string = "abcd";
  int i = 0;
  while (i < 12289) {
      i++;
      try {
          Integer a = (Integer) string;
      } catch (Exception e) {
          e.printStackTrace();
      }
  }

สำหรับรหัสเฉพาะส่วนนี้การทำซ้ำ 12288 (+ ความถี่?) น่าจะเป็นข้อ จำกัด ที่ JVM ตัดสินใจใช้ข้อยกเว้นที่จัดสรรล่วงหน้า ...

exception.toString ไม่ให้ StackTrace แก่คุณ แต่จะส่งคืนเท่านั้น

คำอธิบายสั้น ๆ ของการโยนได้นี้ ผลลัพธ์ที่ได้คือการต่อกันของ:

* the name of the class of this object
* ": " (a colon and a space)
* the result of invoking this object's getLocalizedMessage() method

ใช้exception.printStackTraceแทนการส่งออก StackTrace

คำแนะนำอื่น - หากคุณใช้ Eclipse คุณสามารถตั้งค่าเบรกพอยต์บน NullPointerException ได้เอง (ในมุมมอง Debug ไปที่แท็บ "จุดพัก" และคลิกที่ไอคอนเล็ก ๆ ที่มี!)

ตรวจสอบทั้งตัวเลือก "จับ" และ "ไม่ถูกจับ" - ตอนนี้เมื่อคุณทริกเกอร์ NPE คุณจะเบรกพอยต์ทันทีและจากนั้นคุณสามารถก้าวผ่านและดูว่ามันถูกจัดการอย่างไรและทำไมคุณถึงไม่ได้รับการติดตามสแต็ค

toString()คืนค่าชื่อข้อยกเว้นและข้อความทางเลือกเท่านั้น ฉันขอแนะนำให้โทร

exception.printStackTrace()

เพื่อทิ้งข้อความหรือถ้าคุณต้องการรายละเอียดเต็มไปด้วยเลือด:

 StackTraceElement[] trace = exception.getStackTrace()

(คำถามของคุณยังไม่ชัดเจนว่ารหัสของคุณโทรมาprintStackTrace()หรือกำลังดำเนินการโดยตัวจัดการการบันทึก)

ต่อไปนี้เป็นคำอธิบายที่เป็นไปได้เกี่ยวกับสิ่งที่อาจเกิดขึ้น:

• ตัวบันทึก / การจัดการที่ใช้ถูกกำหนดค่าเพื่อส่งออกเฉพาะสตริงข้อความของข้อยกเว้นไม่ใช่การติดตามสแต็กเต็ม

• แอปพลิเคชันของคุณ (หรือบางไลบรารีของบุคคลที่สาม) กำลังบันทึกข้อยกเว้นโดยใช้LOG.error(ex);แทนที่จะเป็นรูปแบบ 2 อาร์กิวเมนต์ของ (ตัวอย่าง) เมธอด log4j Logger

• ข้อความมาจากที่อื่นที่คุณคิดว่าเป็น; เช่นมันกำลังจะมาถึงวิธีห้องสมุดของบุคคลที่สามหรือบางสิ่งที่สุ่มมาจากการพยายามแก้ไขข้อผิดพลาดก่อนหน้า

• ข้อยกเว้นที่ถูกบันทึกไว้มีการโหลดวิธีการมากเกินไปเพื่อปิดบัง stacktrace หากเป็นเช่นนั้นข้อยกเว้นจะไม่ใช่ของแท้ NullPointerException แต่จะเป็นประเภทย่อยที่กำหนดเองของ NPE หรือแม้กระทั่งข้อยกเว้นบางส่วนที่ไม่ได้เชื่อมต่อ

ฉันคิดว่าคำอธิบายที่เป็นไปได้ครั้งสุดท้ายนั้นไม่น่าเป็นไปได้ แต่อย่างน้อยผู้คนคิดว่าทำอย่างนี้เพื่อ "ป้องกัน" วิศวกรรมย้อนกลับ แน่นอนว่ามันจะประสบความสำเร็จในการทำให้ชีวิตของผู้พัฒนาที่ซื่อสัตย์ซื่อสัตย์

เมื่อคุณใช้ AspectJ ในโครงการของคุณอาจเกิดขึ้นที่บางแง่มุมซ่อนส่วนของการติดตามสแต็ก ตัวอย่างเช่นวันนี้ฉันมี:

java.lang.NullPointerException:
  at com.company.product.MyTest.test(MyTest.java:37)

การติดตามสแต็กนี้ถูกพิมพ์เมื่อรันการทดสอบผ่านทาง Surefire ของ Maven

ในทางตรงกันข้ามเมื่อรันการทดสอบใน IntelliJ จะมีการพิมพ์การติดตามสแต็กที่แตกต่างกัน:

java.lang.NullPointerException
  at com.company.product.library.ArgumentChecker.nonNull(ArgumentChecker.java:67)
  at ...
  at com.company.product.aspects.CheckArgumentsAspect.wrap(CheckArgumentsAspect.java:82)
  at ...
  at com.company.product.MyTest.test(MyTest.java:37)

สิ่งนี้จะส่งออกข้อยกเว้นใช้เพื่อแก้ไขข้อบกพร่องคุณควรจัดการกับข้อยกเว้นที่ดีกว่า

import java.io.PrintWriter;
import java.io.StringWriter;
    public static String getStackTrace(Throwable t)
    {
        StringWriter sw = new StringWriter();
        PrintWriter pw = new PrintWriter(sw, true);
        t.printStackTrace(pw);
        pw.flush();
        sw.flush();
        return sw.toString();
    }