我正試圖了解作業系統和編程語言中中斷/例外之間的關系。請注意，這只是基于我的理解，我可能是完全不正確的。
- 中斷通常是由硬體發起的。軟體中斷也是存在的--我有一個問題，我在下面提到。
- 例外分為3種型別--陷阱、故障和中止
JDK 中是否有關于 trap、fault、abort 類別的例子？我知道這些是作業系統的概念，但我想至少有一部分編程語言的例外可能屬于這些類別。
軟體中斷和陷阱（屬于例外）之間有什么區別？
Java中是否有關于陷阱的例子？我認為那些導致系統呼叫的（如打開一個檔案）可以是軟體中斷陷阱。
我有Java背景，當我想到Java（或任何編程語言）中的Exceptions時，我正試圖將我的大腦包裹在這些概念中。
我特別想了解由編程語言提供的處理程式（不必局限于 Java）與由內核提供的處理程式之間的關系，以處理中斷和例外。
我知道這是個口誤，謝謝你的時間。
uj5u.com熱心網友回復：
你混淆了硬體例外和軟體例外，前者被分為3種型別（陷阱、故障和中止），后者通常不是。
陷阱、故障和中止之間的區別在于例外發生后機器的狀態，并影響到是否可以繼續執行，以及是否會重新執行導致例外的指令，或之后的指令。
軟體例外通常是以呼叫某個例程開始的，該例程的名稱是signal、raise或throw。然后，例外調度器使用設計者認為合適的規則來搜索一個處理程式。
（請注意，硬體例外可能被轉化為軟體例外--例如，硬體捕獲到一個已知的地址，然后該處理程式有效地 "引發 "了一個軟體例外）。
根據機制的設計，軟體例外可能是可持續的，也可能不是。 Java 例外是不可持續的；在進入例外處理程式（'catch'陳述句）之前，堆疊已經被解開。所以，如果你真的想把 Java 例外映射到 trap/fault/abort 分類中，最接近的匹配是'abort'。
其他語言有不同的想法--處理程式可能在堆疊解開之前進入，處理程式可以解開堆疊，否則就從例外點繼續，可能在修復問題之后。 但是現在，這種方法（'恢復語意'）已經不受歡迎了，而傾向于使用不可持續的例外（'終止語意'）。
總結：軟體系統或編程語言定義了它的例外概念。 硬體也有類似但不完全相同的關注點，但作業系統或運行時系統有必要將硬體動作映射為軟體例外。 例如，可能出現的情況是，硬體陷入了內核模式，但軟體例外需要傳遞給用戶模式下的特定程式。
并不總是這樣，軟體例外只是在編程語言中實作。 例如，Windows（以及早期的系統，如 VMS）將結構化的例外處理作為系統級功能提供；語言功能可能建立在此基礎之上，但所有程式都可以使用這一基本理念，包括那些用匯編代碼撰寫的程式。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/318127.html
標籤：
上一篇：如何防止sed插入空白？