ทำไม Java ไม่อนุญาตให้มีคลาสย่อยทั่วไปของ Throwable

ตามการแยกภาษา Javaรุ่นที่ 3:

มันเป็นข้อผิดพลาดเวลารวบรวมถ้าระดับทั่วไปเป็น subclass Throwableโดยตรงหรือโดยอ้อมของ

ฉันต้องการเข้าใจว่าทำไมการตัดสินใจครั้งนี้จึงเกิดขึ้น เกิดอะไรขึ้นกับข้อยกเว้นทั่วไป

(เท่าที่ฉันรู้ generics เป็นเพียงการรวบรวมเวลา syntactic น้ำตาลและพวกเขาจะถูกแปลเป็นObjectอย่างไรก็ตามใน.classไฟล์ดังนั้นการประกาศคลาสทั่วไปอย่างมีประสิทธิภาพราวกับว่าทุกอย่างในนั้นเป็นObjectโปรดแก้ไขให้ฉันถ้าฉันผิด .)

ตามที่ระบุในเครื่องหมายประเภทจะไม่สามารถนำมาใช้ซ้ำได้ซึ่งเป็นปัญหาในกรณีต่อไปนี้:

try {
   doSomeStuff();
} catch (SomeException<Integer> e) {
   // ignore that
} catch (SomeException<String> e) {
   crashAndBurn()
}

ทั้งสองSomeException<Integer>และSomeException<String>ถูกลบไปเป็นประเภทเดียวกันไม่มีวิธีใดที่ JVM จะแยกความแตกต่างของอินสแตนซ์ของข้อยกเว้นดังนั้นจึงไม่มีวิธีที่จะบอกได้ว่าcatchควรใช้บล็อกใด

นี่คือตัวอย่างง่ายๆของการใช้ข้อยกเว้น:

class IntegerExceptionTest {
  public static void main(String[] args) {
    try {
      throw new IntegerException(42);
    } catch (IntegerException e) {
      assert e.getValue() == 42;
    }
  }
}

เนื้อความของคำสั่ง TRy จะส่งข้อยกเว้นด้วยค่าที่กำหนดซึ่งถูกจับโดยประโยค catch

ในทางตรงกันข้ามห้ามนิยามต่อไปนี้ของข้อยกเว้นใหม่เนื่องจากสร้างชนิดที่กำหนดพารามิเตอร์:

class ParametricException<T> extends Exception {  // compile-time error
  private final T value;
  public ParametricException(T value) { this.value = value; }
  public T getValue() { return value; }
}

ความพยายามรวบรวมข้างต้นรายงานข้อผิดพลาด:

% javac ParametricException.java
ParametricException.java:1: a generic class may not extend
java.lang.Throwable
class ParametricException<T> extends Exception {  // compile-time error
                                     ^
1 error

ข้อ จำกัด นี้มีเหตุผลเพราะเกือบทุกความพยายามในการตรวจจับข้อยกเว้นจะต้องล้มเหลวเนื่องจากประเภทนั้นไม่สามารถรับรองได้ บางคนอาจคาดหวังว่าการใช้ข้อยกเว้นโดยทั่วไปจะเป็นสิ่งต่อไปนี้:

class ParametricExceptionTest {
  public static void main(String[] args) {
    try {
      throw new ParametricException<Integer>(42);
    } catch (ParametricException<Integer> e) {  // compile-time error
      assert e.getValue()==42;
    }
  }
}

สิ่งนี้ไม่ได้รับอนุญาตเพราะประเภทในข้อจับไม่สามารถนำมาใช้ใหม่ได้ ในขณะที่เขียนนี้คอมไพเลอร์ Sun รายงานข้อผิดพลาดทางไวยากรณ์ทั้งหมดในกรณีเช่นนี้:

% javac ParametricExceptionTest.java
ParametricExceptionTest.java:5: <identifier> expected
    } catch (ParametricException<Integer> e) {
                                ^
ParametricExceptionTest.java:8: ')' expected
  }
  ^
ParametricExceptionTest.java:9: '}' expected
}
 ^
3 errors

เนื่องจากข้อยกเว้นไม่สามารถเป็นพารามิเตอร์ได้จึงถูก จำกัด ไวยากรณ์เพื่อให้ชนิดนั้นต้องถูกเขียนเป็นตัวระบุโดยไม่มีพารามิเตอร์ต่อไปนี้

มันเป็นหลักเพราะมันถูกออกแบบในทางที่ไม่ดี

ปัญหานี้ป้องกันการออกแบบนามธรรมที่สะอาดตาเช่น

public interface Repository<ID, E extends Entity<ID>> {

    E getById(ID id) throws EntityNotFoundException<E, ID>;
}

ข้อเท็จจริงที่ว่าประโยคจับจะล้มเหลวสำหรับ generics จะไม่ reified ไม่มีข้อแก้ตัวสำหรับที่ คอมไพเลอร์สามารถไม่อนุญาตให้ใช้ประเภททั่วไปคอนกรีตที่ขยายได้ Throwable หรือไม่อนุญาต generics ภายในข้อจับ

ข้อมูลทั่วไปจะถูกตรวจสอบ ณ เวลารวบรวมเพื่อความถูกต้องของประเภท ข้อมูลประเภททั่วไปจะถูกลบออกแล้วในกระบวนการที่เรียกว่าลบออกประเภท ยกตัวอย่างเช่นจะถูกแปลงเป็นชนิดที่ไม่ใช่ทั่วไปList<Integer>List

เนื่องจากการลบประเภททำให้ไม่สามารถกำหนดพารามิเตอร์ชนิดได้ในขณะใช้งาน

สมมติว่าคุณได้รับอนุญาตให้ขยายThrowableสิ่งนี้:

public class GenericException<T> extends Throwable

ตอนนี้ลองพิจารณาโค้ดต่อไปนี้:

try {
    throw new GenericException<Integer>();
}
catch(GenericException<Integer> e) {
    System.err.println("Integer");
}
catch(GenericException<String> e) {
    System.err.println("String");
}

เนื่องจากการลบประเภทรันไทม์จะไม่ทราบว่า catch block ใดที่จะดำเนินการ

ดังนั้นจึงเป็นข้อผิดพลาดในการคอมไพล์ถ้าคลาสทั่วไปเป็นคลาสย่อยทางตรงหรือทางอ้อมของ Throwable

ที่มา: ปัญหาเกี่ยวกับการลบประเภท

ฉันคาดหวังว่าเป็นเพราะไม่มีวิธีรับประกันพารามิเตอร์ พิจารณารหัสต่อไปนี้:

try
{
    doSomethingThatCanThrow();
}
catch (MyException<Foo> e)
{
    // handle it
}

ในขณะที่คุณทราบการแปรเป็นเพียงน้ำตาลประโยค อย่างไรก็ตามคอมไพเลอร์พยายามตรวจสอบให้แน่ใจว่าการกำหนดพารามิเตอร์ยังคงสอดคล้องกันตลอดการอ้างอิงทั้งหมดไปยังวัตถุในขอบเขตการรวบรวม ในกรณีที่มีข้อยกเว้นคอมไพเลอร์ไม่มีทางที่จะรับประกันได้ว่า MyException จะถูกส่งออกจากขอบเขตที่กำลังประมวลผลเท่านั้น