64,648
社区成员
发帖
与我相关
我的任务
分享让程序回到throw之后继续执行
class Abnormal
{
};
int v()
{
throw "这不对";
cout<<"next";
return 0;
}
int _tmain(int argc, _TCHAR* argv[])
{
try{
v();
}
catch(char * txt)
{
cout<<txt<<endl;
}
return 0;
}
这是一个尝试的程序。运行的结果表明程序在执行了v函数的throw之后调到catch块，在catch块执行完之后就没有回到throw后面执行cout<<"next";能够让catch块执行完之后回去执行throw之后的代码吗？
...全文
请发表友善的回复…
发表回复
几罗星人 2014-07-15
- 打赏
- 举报
1、try-catch有什么用：上面说了，让错误在它应当被捕捉的那一层捕捉，而应当被捕捉的那一层通常不一定是直接调用者。
try-catch所的作用，直接的看，是传递了错误信息。但是根本的作用，是程序的跳转。跳到另一处代码位置继续往下执行，因为即使你没出错，你同样可以用throw跳出去，所以try-catch的根本作用，和是否出错是无关的，只是现在我们通常把它用到了catch一个错误上面。
try-catch是建立在C函数setjmp,longjmp的基础上的，这两个函数就是用来跳转的（和你跳转时是不是出现了运行时错误无关），和goto类似。但是在C语言中，goto只能跳到本函数内的另一个位置，如果需要跳到函数以外就做不到。于是就又提供了一种可以跳到函数之外的方式：setjmp,longjmp。你可以出错了跳出去，没出错你也可以跳出去，只要是你需要跳出去。
所以try-catch的根本作用在于跳转，这个机制的设计之初，就不是用来catch错误的，边都沾不上。
2、try-catch怎么用：尽量不用。就像C语言的goto一样，尽量不用，lz如果学了C的话，一定会注意到很多教材在goto上面都会这样注明。除非万不得已，所以才说try-catch是一种最后的手段。
[/quote]
你这样说的话我也确实看到过书说有人滥用异常机制实现转跳和跨函数的数据传输。或许你的这一段话最实在，并不在乎用他来干什么，只是你想跳出去而已，（有错误+）想跳出去+不明确跳到哪里才用这个，而有错误这个条件本身就是可选的，毕竟没错误你喜欢的话也可以抛一个throw。不想跳出去能自己处理的自己处理，不想跳出去自己不能处理但上一级可以处理的用返回值之类的，都不能处理就只能等死了。
zilaishuichina 2014-07-10
- 打赏
- 举报
1、try-catch有什么用：上面说了，让错误在它应当被捕捉的那一层捕捉，而应当被捕捉的那一层通常不一定是直接调用者。
try-catch所的作用，直接的看，是传递了错误信息。但是根本的作用，是程序的跳转。跳到另一处代码位置继续往下执行，因为即使你没出错，你同样可以用throw跳出去，所以try-catch的根本作用，和是否出错是无关的，只是现在我们通常把它用到了catch一个错误上面。
try-catch是建立在C函数setjmp,longjmp的基础上的，这两个函数就是用来跳转的（和你跳转时是不是出现了运行时错误无关），和goto类似。但是在C语言中，goto只能跳到本函数内的另一个位置，如果需要跳到函数以外就做不到。于是就又提供了一种可以跳到函数之外的方式：setjmp,longjmp。你可以出错了跳出去，没出错你也可以跳出去，只要是你需要跳出去。
所以try-catch的根本作用在于跳转，这个机制的设计之初，就不是用来catch错误的，边都沾不上。
2、try-catch怎么用：尽量不用。就像C语言的goto一样，尽量不用，lz如果学了C的话，一定会注意到很多教材在goto上面都会这样注明。除非万不得已，所以才说try-catch是一种最后的手段。
taodm 2014-07-09
- 打赏
- 举报
异常到底有什么用，去看巨牛b的google 的c++编码规范 就知道答案了。
几罗星人 2014-07-09
- 打赏
- 举报
其实这段话我也并非反对，能事先搞定的就事先搞定，而”至少我个人观点，我不认为真的有需要动态修复的错误。我也不认为回去继续执行是一个正常的想法。“虽然你不认同，但是你这样认为可能有你的道理，或者是你自己的经验中没遇到过。
然而这段话更加令人疑惑。try-catch只能收到throw出来的异常，而其他的错误是收不到，正如下面说的空指针。那如果能throw就意味着你知道就意味着你应该解决，那解决就好了，要throw和try-catch何用？
另外，对zilaishuichina，人家那个网络连接只是个例子，单纯连不上发送失败一般来说是不会真的崩溃的，但是如果是接收数据，然后来个CopyMemory，你说收回来的是空数据，copy之后我再来用会不会出问题呢？
但这不是重点，可能您没发现，这个帖子已经不是讨论try-catch怎么用的问题了，而是try-catch有什么用的问题？也就是我发现我不理解throw-try-catch的”错误处理“这个机制到底有什么用。就目前所听到的，以上的41楼，throw-try-catch除了能传递错误信息外什么都做不了，而传递信息的手段有很多，可能可以跨层传送错误信息算是唯一的好处了。
我所说的是否是空数据完全可以用if来判断。就像这一楼刚开始的，既然我已经想到了可能收到空数据，那么就应该在操作前先if判断，那这样的话就没必要用throw抛出异常了，也没必要用try-catch去捕获异常了。
至于野指针，或者是空指针这些引发的问题，try-catch又捕获不到，真的遇到野指针，空指针这些出的问题你设置了try-catch也只能是听天由命，
几罗星人 2014-07-09
- 打赏
- 举报
从中摘录了一句（当然，我全篇都看过了）。那么就是说你也认为异常只是一种通知机制？如果是这样的话异常的使用本身就没什么作用，就像我以前说的（我自己都忘了在哪一楼了），将throw改成写程序日志可能传达的信息更多~[/quote]
你日志log下来的，可能确实是更常见一点的解决办。
但是有一点，你日志log下来的信息，有时候不一定是想知道出了什么错误的人，他想要的信息。
对于异常，我个人的理解，它的好处是：可以让想知道出错的人，知道出错了，让错误在它应当被捕捉的那一层捕捉；让不想知道出错的人，不用关心出没出错，也不用担心错误信息丢失。而不在于捕捉了之后怎么办，侧重点不一样。
反正这是我个人的观点。举例如下代码：
void fun3()
{
return -1;
}
void fun2()
{
fun3()
}
void fun1()
{
fun2()
}
几罗星人 2014-07-09
- 打赏
- 举报
据查，EXCEPTION_CONTINUE_EXECUTION是忽略一切异常吧[/quote]
EXCEPTION_CONTINUE_EXECUTION是指已经采取了有效措施，返回原执行点执行不会出现异常了才使用的。如果没有采取有效措施直接使用此标识，将陷入死循环。[/quote]
哦，懂了，谢谢
bobo_包子 2014-07-04
- 打赏
- 举报
1. 你这是设计问题，前面已经有人帮你写了可行的方法；
2. 不管其他语言是怎么实现的，c++的异常处理没这种机制。但是并不代表不能实现，c++在发生异常的时候会先搜索异常处理的handler，找到了之后会进行栈展开，这个时候会回到异常发生的地方进行一些清理工作。但是这些都是编译器完成的，我相信有work around的方法，具体怎么做你可以参考下面的文章：http://www.vckbase.com/index.php/wv/1562
建议不要搞这些，你的要求完全是设计问题。
zilaishuichina 2014-07-03
- 打赏
- 举报
参考楼上有人贴出来的代码大全中的一段话：仅在其他编码实践方法无法解决的情况下，才使用异常
异常，只是一种最后的手段。
至少我个人观点，我不认为真的有需要动态修复的错误。我也不认为回去继续执行是一个正常的想法。
你无法前期预见，为什么你能throw出来呢？既然一个异常可以被你的代码throw出来，说明你在写下throw的时候预计到了。
既然你能throw出来，那么就不是lz所说的，用户动作的不确定性，用户的行为你无法判断，这种情况。
既然你能throw出来，说明你清楚的知道，什么样的情况是合法的，可以继续执行的。什么样的情况是非法的，不能继续执行的。
既然你能做出这些判断，你为什么不在try之前先判断好。
你前期预见了但是无法修复，为什么你到了catch中就知道要怎么修复呢？
写catch的人既然知道要怎么修复，为什么不能在try之前修复好呢？
这也是我无法理解的地方。
所以：如果一个异常可以解决，你为什么不在try之前就让它变得合法。你为什么不在异常发生之前，就让它变得正确。
（请注意区别运行时可以解决的异常，和运行时不可以解决的异常）
接上：异常也分程序运行当时可以解决，和运行当时不可以解决的
我并没有说，所有问题都可以在开发期处理，我也没有说，怎样可以写一个无bug的程序。
而是，可以在异常、在catch中处理、并且处理完了还能回去继续执行的，这属于运行当时可以解决的异常，那么应该在异常之前处理掉。
在异常、在catch中无法修复的，这属于运行当时无法解决的异常，同样也就是不可能再回去继续执行的，这可能才是你真正需要用异常的地方。
（如果lz还学过java，你可以再参考一下java中的Exception和Error的区别）
所以重申一下上面的观点，我不认为有需要动态修复的错误。我不认为回去继续执行是一个正常的想法。
出现问题是正常的，依赖于异常来处理问题是不正常的。
尽可能的先处理错误，让程序正常运行，而不是依赖于异常处理，让程序正常运行。
异常，只是一种最后的手段。请先确定，你真的尽了一切可能。
既然lz能明白”不能用异常来推卸责任“，
那么，throw异常的人，先检查别人传入的数据的合法性，就是你的责任。
catch异常的人，了解调用的函数会出什么问题，并传入合法的数据，保证调用的函数不出问题，就是你的责任。
异常，本来就不是用来为你的错误的传值、调用，错误的代码设计买单的。
调用者可以解决，请在调用之前先解决。
不做合法性的检查，依赖异常来做动态修复，才是逃避责任。
zhousitiaoda 2014-07-03
- 打赏
- 举报
不是很懂异常，以前有人说不用异常和滥用异常的都是菜鸟，反正我写代码基本不用，也没觉得非用异常不可的地方。有时候调用第三方或者SDK不捕获异常崩了就崩了，日志+dump改正就是，难道捕获了就一定不会出问题了么
要追问请引用回复 2014-07-03
- 打赏
- 举报
如果是C风格的代码的话，可以试试结构化异常处理（SEH），关键字
__try
__except
__finally
__leave
在VC++中，try catch throw机制是对SEH的封装。
__except中传入EXCEPTION_CONTINUE_EXECUTION可以让程序回到异常点继续执行，表示已经排除了异常
勤奋的小游侠 2014-07-03
- 打赏
- 举报
VB语言设计本身就是不太顾效率，异常处理确实可以到处用。便c++的设计本身就是追求效率，估计任何一本c++教材都会提到异常处理是极其低效的事实。
我觉得楼主误会了c++异常的使用范围。举一个很简单的例子，比如除0异常，有一个c++程序，功能就是用户输入任意两个数，然后计算这两个数相除的结果。作为一个c++程序员，你应该怎么设计？是在计算相除之前，先判断一下除数是不是非0，请用户重新输入？还是直接用一个try catch将它包住？非得等到计算机来个除0异常，才告诉用户重新输入除数，然后再在出错的地方继续执行下去？
如果能够在开发时就能预见到的错误，根本就不应该让计算机抛出异常。如果连开发时都不能预见到会发生什么错误，你凭什么觉得在碰到异常时弹一个对话框让用户重新输入就能够解决这个异常？
除0异常在VB里面可以用异常的方法让用户重新输入解决，在C++则应该在出现这样的异常前就要判断和避免。这就决定了这两门语言的效率和使用人群吧。
baichi4141 2014-07-03
- 打赏
- 举报
异常的用处是“通知调用方发生了错误”，也就是把是否崩溃是否报错是否做什么什么的决定权交给调用方
这是异常的设计目的和存在意义，至少设计者是这么相信的，至于这玩意实际上好不好用见仁见智
如果你没有使用异常的理由，不用就是了，我就是无法理解你非要用异常然后抱怨这玩意不合你意的想法
要追问请引用回复 2014-07-03
- 打赏
- 举报
据查，EXCEPTION_CONTINUE_EXECUTION是忽略一切异常吧[/quote]
EXCEPTION_CONTINUE_EXECUTION是指已经采取了有效措施，返回原执行点执行不会出现异常了才使用的。如果没有采取有效措施直接使用此标识，将陷入死循环。
zilaishuichina 2014-07-03
- 打赏
- 举报
从中摘录了一句（当然，我全篇都看过了）。那么就是说你也认为异常只是一种通知机制？如果是这样的话异常的使用本身就没什么作用，就像我以前说的（我自己都忘了在哪一楼了），将throw改成写程序日志可能传达的信息更多~[/quote]
你日志log下来的，可能确实是更常见一点的解决办。
但是有一点，你日志log下来的信息，有时候不一定是想知道出了什么错误的人，他想要的信息。
对于异常，我个人的理解，它的好处是：可以让想知道出错的人，知道出错了，让错误在它应当被捕捉的那一层捕捉；让不想知道出错的人，不用关心出没出错，也不用担心错误信息丢失。而不在于捕捉了之后怎么办，侧重点不一样。
反正这是我个人的观点。举例如下代码：
void fun3()
{
return -1;
}
void fun2()
{
fun3()
}
void fun1()
{
fun2()
}
zilaishuichina 2014-07-03
- 打赏
- 举报
你能在catch里面写出一种处理，你在这里就能写出一个if
if需要处理的情况，和你在catch里面需要处理的情况的个数，是一一对应的。
try的代价，不一定比if的代价小。
你能catch出网络中断，你就能在这if(网络连通)，这是对应的，少不了的。
你的try，catch同样不能保证，你catch了之后，就不会再断掉了，就一定能发送成功了。
send该失败的，还是会失败。和你是否检测无关。
而你检测send返回的错误码，来决定是否重练重新发送；和你catch下来send的异常，来决定是否重练重新发送。这逻辑根本就是一样的。谁也不比谁的代价小。
而比如每个send，检查其返回的错误码，是编码过程中应该做的事情。
就和你要把send用try包起来，其实还是一样的。
连不上，发送不成功 != 最终导致崩溃
导致崩溃的只能是你设计的不对，比如网络连接成了一个野指针，或者是空指针，而你却依然在使用，导致的崩溃
几罗星人 2014-07-03
- 打赏
- 举报
据查，EXCEPTION_CONTINUE_EXECUTION是忽略一切异常吧
几罗星人 2014-07-03
- 打赏
- 举报
这一套东西可以认真学习一下，谢谢提供~
几罗星人 2014-07-03
- 打赏
- 举报
总结一下吧：其实各位所说的能用try-catch去处理的就能if出来，这确实很多情况都可以，除0，多数用户输入不当这些都可以if，那就没必要使用try-catch。而且能修正的应该在一开始的时候就修正，这句话我在20楼的时候就说了：
请注意有些时候这四个字，这个有些时候不可否认，实在无法解决你还能怎么样。但是可以解决就应当解决。正如11楼的图所说的：”不能用异常来推卸责任“！既然你可以尽一切可能保证调用函数的时候提供正确的信息，以确保调用的函数不会出错，那么你从一开始就应该这样做，而不是依赖异常机制为你找错误还要把错误的信息送到你手上。要找错误，请用调试。而且，例如断网（需要联网的程序）这样的问题，你明明可以等待网络恢复，就不必要抛出throw了。
[/quote]
而完全不可修正的如我31楼所说，用异常通知调用者还不如去写程序日志，详细记录下当前的问题来的实际。反正都解决不了，通知了也无补于事。
至于各位认为没有需要动态修复的问题，那么可以，并不影响讨论。最终有什么情况需要用到异常机制呢？
baichi4141 2014-07-03
- 打赏
- 举报
异常的用处是“通知调用方发生了错误”，也就是把是否崩溃是否报错是否做什么什么的决定权交给调用方
这是异常的设计目的和存在意义，至少设计者是这么相信的，至于这玩意实际上好不好用见仁见智
如果你没有使用异常的理由，不用就是了，我就是无法理解你非要用异常然后抱怨这玩意不合你意的想法
[/quote]
并非说非要用异常，现在帖子的目标已经转到了异常本身的意义何在方面了~[/quote]
在一个到处都是初学者和求代写作业的论坛上讨论语言中某个设计的意义——而且还压根不想去看设计者本人是怎么说的
这种“目标”，好听点是各抒己见，不好听就是自以为是的口水仗
几罗星人 2014-07-03
- 打赏
- 举报
从中摘录了一句（当然，我全篇都看过了）。那么就是说你也认为异常只是一种通知机制？如果是这样的话异常的使用本身就没什么作用，就像我以前说的（我自己都忘了在哪一楼了），将throw改成写程序日志可能传达的信息更多~
加载更多回复（25）
