2010-09-29 244 views
1

我得到以下核心轉儲信息:異常處理

終止叫做拋出 '的std :: out_of_range' 什麼()的一個實例後:basic_string的:: SUBSTR 中止 - 核心轉儲

我從大文件中讀取14位十六進制數字。 ??週期性我注意到有這些空行(好吧,我不知道它是什麼如何處理這個異常可能是嘗試捕捉啄它看起來象下面這樣:

123456789ABCDE 
123456789ABCDE 
123456789ABCDE 

123456789ABCDE 

我不知道是什麼隱藏符號佔據的空間,但其造成的問題,我不知道如何處理this..any想法嗎?也許我能得到如何處理它的樣本?

+3

發佈更多驗證碼;我懷疑你錯過了某處的邊界檢查,但我無法確定。無論如何,您應該在處理數據之前對其進行驗證,而不是捕獲由無效數據導致的異常。 – You 2010-09-29 23:24:57

回答

1

你可能需要包括輸入驗證嘗試之前。轉換決不接受外部輸入的是始終驗證

+0

+1得到一個堅實的評論。我認爲這裏的關鍵點在於,理想情況下,您應該對輸入行進行一般性驗證 - 如果性能不重要,單線性正則表達式可以提供服務 - 而不僅僅是希望您在輸入樂觀處理代碼中執行某些操作恰巧爲你拋出異常(海報問到這個選項)。在業務邏輯層面上,如果沒有單獨的數據處理操作在這種索引和啞數據處理級別上出錯,結果很容易就會出錯。 – 2010-09-30 02:05:26

1

Robustness principle(也被稱爲普天定律):

在 發送的內容中保守;在你接受的東西中自由自在。

所以,一種可能性就是忽略/跳過格式錯誤的行。

+1

從「接受自由」轉向「忽略/跳過格式錯誤的行」是健壯性的一個可疑方法。你希望在考慮可能的投入時保持自由,所以你可以驗證你有合法的投入。因此,接受處理它的意義,但不要猶豫,要在業務邏輯層面拒絕它 - 在這種情況下,適當地強制檢查文件是如何生成的。否則,你可能會掩蓋一個上游的錯誤,無論如何,這個錯誤會回來困擾你,或者破壞你的結果。如果缺少一個值,而不是多餘的換行符是虛假的呢? – 2010-09-30 01:58:31

3

你需要發佈更多的代碼,但從例外看起來像你正在逐行讀取文件並將行存儲在std::string中,然後調用std::string::substr()來提取所需的14個字符。

假設你的代碼如下所示:

std::string str;   /* the lines are stored in this string */ 
std::string substring; /* extracted substring stored here */ 

/* Read file line by line */ 
// ... 

substring = str.substr(index, 14); //extract 14 characters starting at 'index' 

更改爲:

if(str.size() > index) { 
    substring = str.substr(index, 14); 
} 
+0

'substr'靜靜地剪輯返回的範圍,如果它延伸到最後。只檢查'index <= str.size()'就足夠了。 +1,但。 – Potatoswatter 2010-09-30 01:55:37

+0

@Patatoswatter,好點,謝謝,我會更新答案 – Praetorian 2010-09-30 02:04:44

1

別人給予這個specifc問題的具體答案。

但在一般情況來看,這種在一個調試器,看看它拋出。對於gdb,'catch throw'gdb會在發生錯誤的地方斷開。這很明顯,原因是什麼。

0

下面的代碼可能顯示了可能的問題:

#include <iostream> 

int main(){ 
    std::string s = "Hi"; 

    std::string sb = s.substr(14, 0); // extract 0 characters from 
             // an out-of-range 
             // start location 
} 

basic_string<charT,traits,Allocator> 
substr(size_type pos = 0, size_type n = npos) const; 

如果起始索引(第一自變量)是無效的(大於字符串對象的尺寸更大),標準的任務的方法引發「out_of_range '錯誤。

它也像你是不是用的try/catch具有字符串操作。這不是一個好習慣。讓所有可以在try catch塊中引發異常的代碼。這給你一個處理異常的機會(如果你願意的話)。