1996年的6月4日, 歐洲太空總署試射了一架無人駕駛Ariane 5火箭，這個計畫共花了十年和7千萬美金，但是這架火箭居然在發射後的36.7幾秒就爆炸了，意外事件的報告在兩個禮拜後出爐，指出了爆炸原因是因為程式設計的錯誤。
在飛行使用的慣性導航系統(IRS)，正在處理一小段的資料時，因為無法轉換64bit的浮點數到16bit的整數，而造成了overflow的發生，隨即這個系統就關機了，而這段資料也被傳輸到另外一個備用的運算單元，這個重複的運算單元，就是怕原本的系統有問題而增設的，但是在幾毫秒後，這個備用的單元也關機了，原因就是這個系統跟原本的是一模一樣的，所以一樣無法處理那段資料，所以意外就發生了。
照一般程式處理的方式，當這個例外處理產生的時候，因為在realtime的系統上，我們會想辦法回復系統的狀態，而其實Ariane 5的IRS系統也做了很多這樣的處理，而因為這個系統是從Ariane 4就有的，而Ariane 5的速度比Ariane 4還要快上很多，一個無法被處理的值就這樣產生了，而原本Ariane 4的程式卻是假設不可能出現這樣的值（我想應該是為了效能的關係），而這個BUG對應的處理居然是直接關閉系統，也間接干擾了其他的系統。
這個意外導致了很多的損失，追根究底卻是因為一個小小的程式BUG引起的，我想在這個系統越來越複雜的世界，真的有賴工程師的細心，尤其是寫realtime system的設計師，更是需要考慮各種不同的情況去做好例外處理，才能避免類似的情況發生阿。
在飛行使用的慣性導航系統(IRS)，正在處理一小段的資料時，因為無法轉換64bit的浮點數到16bit的整數，而造成了overflow的發生，隨即這個系統就關機了，而這段資料也被傳輸到另外一個備用的運算單元，這個重複的運算單元，就是怕原本的系統有問題而增設的，但是在幾毫秒後，這個備用的單元也關機了，原因就是這個系統跟原本的是一模一樣的，所以一樣無法處理那段資料，所以意外就發生了。
照一般程式處理的方式，當這個例外處理產生的時候，因為在realtime的系統上，我們會想辦法回復系統的狀態，而其實Ariane 5的IRS系統也做了很多這樣的處理，而因為這個系統是從Ariane 4就有的，而Ariane 5的速度比Ariane 4還要快上很多，一個無法被處理的值就這樣產生了，而原本Ariane 4的程式卻是假設不可能出現這樣的值（我想應該是為了效能的關係），而這個BUG對應的處理居然是直接關閉系統，也間接干擾了其他的系統。
這個意外導致了很多的損失，追根究底卻是因為一個小小的程式BUG引起的，我想在這個系統越來越複雜的世界，真的有賴工程師的細心，尤其是寫realtime system的設計師，更是需要考慮各種不同的情況去做好例外處理，才能避免類似的情況發生阿。
