一个关于异常是否应该throw的问题

[crystal_lz]

我就想问一下 平时在写一些模块的时候 一些方法里面是否 应该抛异常的问题
举个例子 假设我写一个 方法来返回两个数相除的结果

public double Add(double a,double b){
    if(b == 0)
        throw new ArgumentException("除数不能为零");
    return a / b;
}

里面的 那个异常到底要不要写呢？、如果不写的话 到时候执行return的时候 .Net 也会提示异常的 你写了的话还是要提示 只不过 一个是你的 一个是内置的 所以很多次都纠结这个问题 到底一些异常要不要手动抛出、、

[exception92]

对于一些可以预估的异常，在用户输入或者执行的时候 都想法用 校验 给它屏蔽了. 比如你这 b 不能为0，就加一个判断，如果输入0，就提示不能输入0，不执行下边的操作 （return）,这样就不用throw了。 还有一些 不能预估的异常，比如 提交数据到数据库，可能你从开始写sql语句到执行 都不知道 缺少一个 分号。这时候使用 try catch 捕获异常，能详细的提示错误在哪里。不过 try catch 比较损耗 性能。

[maximelei]

寫了以後, 有利於看LOG

[enaking]

我在项目里从来不写，对大项目调试会找不到出错的地方。 try catch也一般在读写文件或数据库时写，这样更好调试，

[wfy4422]

有时候我也会纠结。我觉得是要看情况的，除数为零的情况最好不要抛异常，用业务逻辑控制更好些，b为零时作适当的处理，不用弹提示了。我觉得异常最大的用处是调试程序及发现BUG，并不是提示给用户的，所以业务逻辑方面不要抛异常，比较底层一点的类最好抛。

[wangnaisheng]

弹出一些提示信息不好嘛

[於黾]

内置的异常有些是用户看不懂的,需要翻译成用户能看懂的异常再给用户. 而除数为0的,你直接可以用if来判断,返回个bool型的变量,没必要抛异常.

[youzelin]

针对你举得例子，这个异常可以直接抛出来，这是最 simple 的方式。 还可以自己包一层 try-catch，在 catch 里面处理异常，可以把那个异常包裹一层，形成自定义的异常。 如果你要说不 throw 的话，我觉得说不过去，至少是针对你这个例子，我觉得应该要抛，不能吞掉。

[刘小安]

一般你写在最底层的时候，都是需要throw的，上面调用的时候捕获异常，然后根据异常类型给用户看你总结的异常类型。

[jimil]

throw new ArgumentException("除数不能为零"); 最好不要这样写。 MessageBox.Show("除数不能为零"); 这样更好更直观，通常我们所说的异常即为系统内部出错，c#比vb强的地方就是结构严谨，像这种提示就应该用messagebox，像楼主你应该处在学习阶段吧，如果可以，学习怎么制作出错提示窗体，而不是用简单的messagebox。当然，像这种功能也可以搞验证控件，也可以用LABEL显示输入错误，总之，结构上说，不推荐使用throw

[来一脚]

throw用来抓住以下不可预期的错误。明显你这个一眼就能判断了，不要滥用throw

[bwangel]

就你这个例子来说，有点画蛇添中。既然你不打算在本层处理异常，那就不需要多此一举。 因为你不抛系统也会抛。 关键是调用它的上层如何处理这个异常。