Rust Java C Python Dart C 异常处理 Go (rustjava)
本文目录导航:
C、C++、Java、Python、Go、Rust、Dart 异常处理
本文为七种语言对比学习的第十六篇:异常处理。
程序中往往会出现错误和异常。
错误会导致程序崩溃和运行出错,而异常则能得到处理并恢复,下文将异常和错误统称为异常。
C语言不直接提供错误处理,但作为系统编程语言,它以返回值的形式允许访问底层数据。
C语言中,正常退出会返回0;在发生错误时,大多数的C函数返回1或-1,同时会设置一个错误代码errno,该错误代码为全局变量,表示在函数调用期间发生了错误。
C语言提供了perror()和strerror()函数来显示与errno相关的消息。
perror()函数显示传给它的字符串,strerror()函数返回一个指针,指针指向当前errno值的文本表示。
C++语言提供错误处理机制:C++语言提供异常处理机制,通过try-catch块来捕获并处理异常。
Java语言提供错误处理机制:Java语言利用try-catch-finally块来处理异常,其中try块包含可能抛出异常的代码,catch块捕获并处理异常,finally块包含异常处理后的清理代码。
Python异常处理:Python自带一套错误断言,处理机制,通过try-except语句捕获并处理异常。
Go语言通过内置的错误error接口提供了非常简单的错误处理机制。
error类型是一个接口类型,它的定义如下:error接口定义了一个方法Error(),该方法返回一个字符串描述错误。
在编码中通过实现error接口类型来生成错误信息,通常在最后的返回值中返回错误信息。
使用可返回一个错误信息:err := (出错啦!)。
大部分函数调用都会返回两个值,一个值,一个错误err,可以利用err值判断。
Rust有一套独特的处理异常情况的机制,它不像Python中的try机制那样简单。
对于可恢复错误,可使用Result来处理,不可恢复用panic!,match用于匹配正常或错误情况。
Dart自带异常处理,且异常本身可被传递。
Dart提供异常和错误的类型以及预定义的子类,也可以预定义自己的异常子类,Dart允许抛出任意类型的非空对象作为一个异常。

混合使用C++和C代码时的异常处理注意事项
异常机制允许函数在出错时抛出异常,调用者可以选择捕获并处理这些异常,从而灵活控制程序的行为。
这与传统的错误处理方法(如无条件终止、返回错误值、使程序处于非法状态或调用预定义错误处理函数)相比,更为清晰、优雅,并提供了更好的灵活性和控制力。
C++的异常机制为程序员提供了一种自然的方式来处理错误,使得编写健壮、可靠的代码更为容易。
异常实战入门假设我们写一个程序,把用户输入的两个字符串转换为整数,相加输出,一般我们会这么写。
然而,用户的输入有可能误操作,输入了非法字符,例如。
这个时候结果是1,因为atoi(str2)返回0。
如果用户输入是这样,那么这段代码会出现段错误,程序异常退出。
atoi我觉得是一个比较危险的函数,如果在一个重要系统中,调用者不知情,传入了一个NULL字符,程序就异常退出了,导致服务中断,或者传入非法字符,结果返回0,代码继续走下去,在复杂的系统中想要定位这个问题,真是很不容易。
所以比较合适的方式,是我们用异常处理改造一个安全的atoi方法,叫parseNumber。
上述代码中NumberParseException是自定义的异常类,当我们检测的时候传入的str不是一个数字时,就抛出一个数字转换异常,让调用者处理错误,这比传入NULL字符串,导致段错误结束程序好得多,调用者可以捕获这个异常,决定是否结束程序,也比传入一个非整数字符串,返回0要好,程序出现错误,却继续无声无息执行下去。
于是我们之前写的代码可以改造如下。
这段代码的结果是打印出输入不是整数。
假设这段代码是运行在一个游戏统计系统中,系统需要定时从大量文件中统计大量用户进入游戏频道1和游戏频道2的次数,str1代表进入游戏频道1的次数,str2表示进入频道2的次数,如果不是使用异常,当输入是NULL程序会导致整个系统宕机,当输入是非法整数,计算结果全部是错误的,当时程序仍然无声无息正确执行。
输入非法,抛出NumberParseException,即使调用者没有考虑输入是非法的,例如是。
就算调用者比较粗心,没有捕获异常,程序运行中会抛出NumberParseException,程序宕机,会留下coredump文件,调用者通过gdb 程序名 coredump文件,查看程序宕机时的堆栈,就知道程序运行中,出现了非法整数字符,那么他就很快知道问题所在,会学乖,把上述代码改成。
这样,下次程序出现问题时,调用者就可以定位问题所在了,这就是异常的错误处理方式,把错误的发现(parseNumber)和错误的处理(游戏统计代码)分开。
这里介绍了异常的抛出和捕获,还有异常的使用场景,接下来就开始一步步讲解C++异常。
异常的描述函数和函数可能抛出的异常集合作为函数声明的一部分是有价值的。
例如,表示f()只能抛出两个异常x2,x3,以及这些类型派生的异常,但不会抛出其他异常。
如果f函数违反了这个规定,抛出了x2,x3之外的异常,例如x4,那么当函数f抛出x4异常时, 会转换为一个std::unexpected()调用,默认是调用std::terminate(),通常是调用abort()。
如果函数不带异常描述,那么假定他可能抛出任何异常。
例如:不带任何异常的函数可以用空表表示:捕获异常捕获异常的代码一般如下:1.如果H和E是相同的类型2.如果H是E的基类3.如果H和E都是指针类型,而且1或者2对它们所引用的类型成立4.如果H和E都是引用类型,而且1或者2对H所引用的类型成立从原则上来说,异常在抛出时被复制,我们最后捕获的异常只是原始异常的一个副本,所以我们不应该抛出一个不允许抛出一个不允许复制的异常。
此外,我们可以在用于捕获异常的类型加上const,就像我们可以给函数加上const一样,限制我们,不能去修改捕捉到的那个异常。
还有,捕获异常时如果H和E不是引用类型或者指针类型,而且H是E的基类,那么h对象其实就是H h = E(),最后捕获的异常对象h会丢失E的附加携带信息。
异常处理的顺序我们之前写的parseNumber函数会抛出NumberParseException,这个函数只是判断是否数字才抛出异常,但是没有考虑,但这个字符串表示的整数太大,溢出,抛出异常Overflow.表示如下。
假设我们parseNumber函数已经为字符串的整数溢出做了检测,遇到这种情况,会抛出Overflow异常,那么异常捕获代码如下。
异常组织这种层次结构对于代码的健壮性很重要,因为库函数发布之后,不可能不加入新的异常,就像我们的parseNumber,第一次发布时只是考虑输入是否一个整数的错误,第二次发布时就考虑了判断输入的一个字符串作为整数是否太大溢出,对于一个函数发布之后不再添加新的异常,几乎所有的库函数都不能接受。
如果没有异常的层次结构,当函数升级加入新的异常描述时,我们可能都要修改代码,为每一处调用这个函数的地方加入对应的catch新的异常语句,这很让你厌烦,程序员也很容易忘记把某个异常加入列表,导致这个异常没有捕获,异常退出。
而有了异常的层次结构,函数升级之后,例如我们的parseNumber加入了Overflow异常描述,函数调用者只需要在自己感兴趣的调用场景加入catch(Overflow),并做处理就行了,如果根据不关心Overflow错误,甚至不用修改代码。
未捕获的异常如果抛出的异常未被捕捉,那么就会调用函数std::terminate(),默认情况是调用abort,这对于大部分用户是正确选择,特别是排错程序错误的阶段(调用abort会产生coredump文件,coredump文件的使用可以参考博客的 学会用core dump调试程序错误)。
如果我们希望在发生未捕获异常时,保证清理工作,可以在所有真正需要关注的异常处理之外,再在main添加一个捕捉一切的异常处理,例如。
重新抛出当我们捕获了一个异常,却发现无法处理,这种情况下,我们会做完局部能够做的事情,然后再一次抛出这个异常,让这个异常在最合适的地方地方处理。
例如。
这个函数是从远程服务器下载文件,内部调用连接到远程服务器的函数,但是可能存在着网络异常,如果多次重连无法成功,就把这个网络异常抛出,让上层处理。
重新抛出是采用不带运算对象的throw表示,但是如果重新抛出,又没有异常可以重新抛出,就会调用terminate();假设NetworkException有两个派生异常叫FtpConnectException和HttpConnectException,调用connect_to_server时是抛出HttpConnectException,那么调用downloadFileFromServer仍然能捕捉到异常HttpConnectException。
标准异常到了这里,你已经基本会使用异常了,可是如果你是函数开发者,并需要把函数给别人使用,在使用异常时,会涉及到自定义异常类,但是C++标准已经定义了一部分标准异常,请尽可能复用这些异常,标准异常参考 /reference...虽然C++标准异常比较少,但是作为函数开发者,尽可能还是复用c++标准异常,作为函数调用者就可以少花时间去了解的你自定义的异常类,更好的去调用你开发的函数。
nx120捕获到标准c异常怎么办
当NX 12.0捕获到标准C++异常时,可以采取以下几种方法来解决这一问题:1. **更新显卡驱动**:很多时候,这种异常与显卡驱动不兼容或过时有关。
尝试更新到最新的显卡驱动程序,这有助于解决图形处理中的问题。
2. **检查系统兼容性**:确保你的操作系统与NX 12.0版本兼容。
有时,软件与操作系统的新版本之间可能存在不兼容问题。
3. **重新安装NX 12.0**:如果更新显卡驱动后问题依旧存在,考虑卸载并重新安装NX 12.0。
在安装过程中,确保遵循官方的安装指南,并将软件安装在无中文路径的文件夹中。
4. **检查软件插件和扩展**:如果你安装了NX的插件或扩展,确保它们与NX 12.0版本兼容。
不兼容的插件可能导致程序异常。
5. **查看日志文件**:NX通常会在出现错误时生成日志文件。
检查这些日志文件可能会提供更多关于异常原因的线索。
6. **联系技术支持**:如果以上方法都不能解决问题,建议联系Siemens PLM Software的技术支持团队,以获取专业的帮助。
通过这些步骤,你应该能够诊断并解决NX 12.0捕获到的标准C++异常问题。