2010-09-29 247 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块中引发异常的代码。这给你一个处理异常的机会(如果你愿意的话)。