如何捕获 strcpy_s 函数异常

[ljcomm]

学艺不精啊~~~~~~
环境为windows7/vs2010. release版本中，按照查阅的资料，使用了__try __except(1) , try catch(...), _set_se_translator(), /EHa , /EHs各种组合都捕获不到strcpy_s的异常，程序直接被windows枪毙。代码如下：
#include <iostream>
int main()
{
char * p=NULL;
try
{
strcpy_s(p,20,"1234567890");
std::cout<<p;
}
catch(...)
{
std::cout<<"捕获到异常";
}
return 0；
}

编译参数使用 /EHa和/EHs 都捕获不到异常
使用_set_se_translator()将结构化异常转换为C++异常后，也捕获不到异常。
如果换成strcpy()函数，很容易捕获到异常。
实在搞不明白strcpy_s()的异常机制。

[mujiok2003]

SEH(使用结构化异常)

[mujiok2003]

#define _CRT_SECURE_NO_WARNINGS

#include <iostream>
#include <Windows.h>
int main()
{
	char * p = NULL;
	__try
	{
		strcpy(p, "1234567890");
		std::cout << p;
	}
	__except (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION)
	{
		std::cout << "捕获到异常";
	}
	return 0;
}

[mujiok2003]

使用xxx_s函数的话，crt会自动调用_invalid_parameter_noinfo来终止程序。

[赵4老师]

磁盘满了，IO异常，不通过报错，强制停止系统通知人并让人来手动解决；而企图让程序捕获所谓的异常后自动运行相关所谓能自动修复错误的代码来解决？！ 恐怕世界末日会因此提前几百亿年到来也说不定！！

[「已注销」]

用 AddVectoredExceptionHandler 试试，__try 应该能捕获有所的。

[Adol1111]

引用 10 楼 zhao4zhong1 的回复:

磁盘满了，IO异常，不通过报错，强制停止系统通知人并让人来手动解决；而企图让程序捕获所谓的异常后自动运行相关所谓能自动修复错误的代码来解决？！ 恐怕世界末日会因此提前几百亿年到来也说不定！！

为什么一定要去运行所谓的自动修复错误的代码，保证其他的功能能够正常进行不行吗？只要停止该项功能提示错误信息就可以了，如果一定要解决，再让用户手动停止不行吗？ 如果是对于程序员，早点弹出错误当然是最好的，但用户就难说了，大部分人最不想看的就是错误，特别是一弹出错误，整个系统全部瘫痪。

[zhuobattle]

启用dump上传机制就可以了。什么问题都在开发前能发现，那是不可能的。 如果这样想只能说你写的程序永远只在自己机器上跑跑而已。

[zhcosin]

这个本来就没有异常抛出，直接崩溃。

[zhcosin]

反正我是从来不用微软搞的那些扩展的，一个比一个无聊。

[赵4老师]

捕获再多的异常也不如 Windows： 崩溃的时候在弹出的对话框按相应按钮进入调试，按Alt+7键查看Call Stack里面从上到下列出的对应从里层到外层的函数调用历史。双击某一行可将光标定位到此次调用的源代码或汇编指令处。 Linux： 进程意外退出会在当前目录下产生‘core’文件或形如‘core.数字’的文件比如‘core.1234’ 使用命令 gdb 运行程序名 core或core.数字 进入gdb然后使用bt命令 可以查看进程意外退出前函数调用的堆栈，内容为从上到下列出对应从里层到外层的函数调用历史。 如果进程意外退出不产生core文件，参考“ulimit -c core文件最大块大小”命令

[ljcomm]

引用 1 楼 zhao4zhong1 的回复:

捕获再多的异常也不如 Windows： 崩溃的时候在弹出的对话框按相应按钮进入调试，按Alt+7键查看Call Stack里面从上到下列出的对应从里层到外层的函数调用历史。双击某一行可将光标定位到此次调用的源代码或汇编指令处。 Linux： 进程意外退出会在当前目录下产生‘core’文件或形如‘core.数字’的文件比如‘core.1234’ 使用命令 gdb 运行程序名 core或core.数字 进入gdb然后使用bt命令 可以查看进程意外退出前函数调用的堆栈，内容为从上到下列出对应从里层到外层的函数调用历史。 如果进程意外退出不产生core文件，参考“ulimit -c core文件最大块大小”命令

大哥，你那是事前的调试，对真正运行的程序无效。调试再多也不能保证运行时100%不出错，捕获异常是保证程序安全运行的必须手段。

[luciferisnotsatan]

http://social.msdn.microsoft.com/Forums/en-US/9d7ee5ef-e062-430f-9343-822b6dd54f93/how-to-avoid-strcpys-exception-when-buffer-overloaded?forum=vcgeneral 里面回复里的那个Invalid Parameter Handler Routine连接 估计是_set_invalid_parameter_handler这个原始处理方法里，直接abort了。 strcpy_s dest为null时，会调用到使用_set_invalid_parameter_handler设置的处理函数。

[赵4老师]

如果啥异常都能捕获的话，试问DNA能进化出人类吗？

[赵4老师]

从计算机诞生以来，有哪个程序100%安全运行过？！

[Adol1111]

引用 4 楼 zhao4zhong1 的回复:

如果啥异常都能捕获的话，试问DNA能进化出人类吗？

你咋知道不能呢？说不定1000年以后有人就做到了

引用 5 楼 zhao4zhong1 的回复:

从计算机诞生以来，有哪个程序100%安全运行过？！

100%安全是不可能的，但可以尽量避免程序出错。你能保证弹出的所有错误，都能在开发阶段都解决掉？ 在正式给用户使用的时候，难道动不动就弹出一个错误？异常不是用来处理逻辑错误的，比如正常情况下的除0异常等等，都应该在开发阶段解决掉。但一些意外的bug，比如磁盘满了，IO异常，难道一定要通过报错，强制停止来解决？