为什么要抛出异常? (为什么要抛出股票)
本文目录导航：
为什么要抛出异常?
在程序设计中，抛出异常是一个重要的机制，用于处理可能出现的错误或异常情况。
通过抛出异常，可以将错误从发生错误的地方传递到更高层次的调用者处理，从而避免程序在错误发生时崩溃。
比如，我们有三个方法：A调用B，B调用C。
我们可以在B和C方法中定义throws Exception。
在A方法中，我们定义了try catch块。
当C方法执行过程中遇到异常时，这个异常会被C方法抛出，然后传递给B，再由B传递给A。
A方法中的try catch块可以捕获这个异常，并允许我们在catch块中编写相应的处理代码来解决这个问题。
如果A方法也定义了throws Exception，那么异常会被继续抛出，直到遇到一个能处理它的方法，或者最终由Java虚拟机来处理。
这种机制确保了异常能够被层层传递，直到找到一个能够妥善处理它的处理者。
通过这种方式，我们可以将错误处理的责任分配给最合适的层次，从而使得程序更加健壮和易于维护。
此外，这种方法也使得代码更加清晰，因为错误处理的逻辑被分离出来，而不是直接嵌入到业务逻辑中。
值得注意的是，虽然使用异常处理可以提高程序的健壮性，但过度使用也可能导致代码复杂性增加。
因此，在实际开发中，需要合理使用异常处理机制，确保它能够有效地帮助我们解决问题，而不是成为代码混乱的根源。
总之，通过抛出异常，我们能够有效地处理程序中的错误情况，确保程序能够更加健壮地运行。
正确地使用异常处理机制，可以使代码更加清晰、易于维护，并且能够更好地处理各种错误情况。
c语言的异常处理
C语言设计之初并没有考虑异常处理机制，因此其异常处理能力相对较弱。
在C语言中，开发者需要通过其他方式如返回值或者全局变量来处理程序运行时可能出现的错误。
例如，当函数执行过程中遇到错误时，可能会返回一个特定的错误码或者修改一个全局变量的值来通知调用者发生了错误。
然而，随着C++语言的出现，异常处理机制被引入到C++中。
C++中的异常处理机制可以更方便地处理运行时错误，提高了代码的可维护性和可读性。
在C++中，开发者可以使用try-catch语句来捕捉异常，并通过throw语句抛出异常。
这使得错误处理变得更加灵活和强大。
尽管C语言本身没有内置的异常处理机制，但通过引入其他技术，如宏定义和自定义函数，可以实现类似的功能。
例如，可以通过宏定义来封装错误处理逻辑，或者通过自定义函数来处理错误情况。
这种方法虽然可以实现错误处理，但与C++的异常处理机制相比，灵活性和可读性较低。
总结来说，C++语言相比C语言在异常处理方面有了很大的改进。
尽管C语言可以通过一些技巧实现类似的功能，但其处理方式不如C++灵活和强大。
在实际开发中，如果需要处理复杂的错误情况，推荐使用C++的异常处理机制。
混合使用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++标准异常，作为函数调用者就可以少花时间去了解的你自定义的异常类，更好的去调用你开发的函数。
phper