在Java中，對那些要調用方法的客戶程序員，我們要通知他們可能從自己的方法裡“擲”出違例。這是一種有禮貌的做法，只有它才能使客戶程序員准確地知道要編寫什麼代碼來捕獲所有潛在的違例。當然，若你同時提供了源碼，客戶程序員甚至能全盤檢查代碼，找出相應的throw語句。但盡管如此，通常並不隨同源碼提供庫。為解決這個問題，Java提供了一種特殊的語法格式（並強迫我們采用），以便禮貌地告訴客戶程序員該方法會“擲”出什麼違例，令對方方便地加以控制。這便是我們在這裡要講述的“違例規范”，它屬於方法聲明的一部分，位於自變量（參數）列表的後面。
違例規范采用了一個額外的關鍵字：throws；後面跟隨全部潛在的違例類型。因此，我們的方法定義看起來應象下面這個樣子：
void f() throws tooBig, tooSmall, divZero { //...
若使用下述代碼：
void f() [ // ...
它意味著不會從方法裡“擲”出違例（除類型為RuntimeException的違例以外，它可能從任何地方擲出——稍後還會詳細講述）。
但不能完全依賴違例規范——假若方法造成了一個違例，但沒有對其進行控制，編譯器會偵測到這個情況，並告訴我們必須控制違例，或者指出應該從方法裡“擲”出一個違例規范。通過堅持從頂部到底部排列違例規范，Java可在編譯期保證違例的正確性（注釋②）。
②：這是在C++違例控制基礎上一個顯著的進步，後者除非到運行期，否則不會捕獲不符合違例規范的錯誤。這使得C++的違例控制機制顯得用處不大。
我們在這個地方可采取欺騙手段：要求“擲”出一個並沒有發生的違例。編譯器能理解我們的要求，並強迫使用這個方法的用戶當作真的產生了那個違例處理。在實際應用中，可將其作為那個違例的一個“占位符”使用。這樣一來，以後可以方便地產生實際的違例，毋需修改現有的代碼。
