前言
对上节异常的补充，也可以说是异常使用的注意事项。
正文
减少try catch的使用
前面提及到，如果一个方法没有实现该方法的效果，那么就应该抛出异常。
如果有约定那么可以按照约定，如果约定有歧义，那么还是要抛出异常。
我们知道使用try catch 其实是要消耗性能的，那么是否能避免使用try catch呢？或者减少使用try catch呢？
我们使用api的时候，知道http制定了一套错误码，那么我们是否能使用错误码返回来做一个约定的呢？
答案是否定的，且不论我们的业务的不同，错误码制定的困难，单是方法里面使用错误码偶和性就非常大。
既然无法通过约定一套错误码来解决，那么是否可以先验证该方法能否执行成功呢？
public class ArrayWorker
{
int[] arrays = { 10, 9, 8, 7, 6 };
public bool tryWorker(int index)
{
if (arrays.Length >index&&index>-1)
{
return true;
}
return false;
}
public int DoWorker(int index)
{
return arrays[index];
}
}
调用:
static void Main(string[] args)
{
ArrayWorker arrayWorker = new ArrayWorker();
if (arrayWorker.tryWorker(-1))
{
arrayWorker.DoWorker(-1);
}
else
{
//错误处理
}
}
调用前可以先检测是否可以执行成功，如果执行成功再去执行，如果不行进行另外的处理。
当然这种存在局限性，比如说检查条件复杂等。
异常块using 和 try finally
我们知道如果非托管资源，且实现了正常的IDisposable,那么我们有两个时候可以去释放资源，一个是我们主动调用dispose，还有一个我们在finalizer中释放。
那么哪个好呢？当然是dispose中了，原因很简单，如果在finalizer中释放，意味着我们的非托管资源在内存中的事件下降，还有一个我在托管中提及到的所以终结器是单线程，我们是不希望放在这里面去非托管资源的，因为堵塞。
我通常使用using来避免自己忘记释放资源，有时候也使用try finally，这样写是否代码风格不统一呢？还是说他们之间有区别呢?
public static void excecuteCommond(string connectString, string commonString)
{
SqlConnection sqlConnection = null;
try
{
sqlConnection = new SqlConnection(connectString);
SqlCommand sqlCommand = null;
try
{
sqlCommand = new SqlCommand(commonString, sqlConnection);
}
finally
{
sqlCommand?.Dispose();
}
}
finally
{
sqlConnection?.Dispose();
}
}
public static void excecuteCommond1(string connectString, string commonString)
{
using (SqlConnection sqlConnection = new SqlConnection(connectString))
{
using (SqlCommand sqlCommand = new SqlCommand(commonString,sqlConnection))
{
}
}
}
上面两个方法在IL上是相等的。实际上using是try finally的语法糖。但是呢，我们写嵌套using，实际上是写嵌套try finally。
有些人不喜欢嵌套try finally,所以会这样写:
public static void excecuteCommond(string connectString, string commonString)
{
SqlConnection sqlConnection = null;
SqlCommand sqlCommand = null;
try
{
sqlConnection = new SqlConnection(connectString);
sqlCommand = new SqlCommand(commonString, sqlConnection);
}
finally
{
sqlCommand?.Dispose();
sqlConnection?.Dispose();
}
}
然后在非托管异常处理中，发现sqlConnection不仅提供Dispose方法还是存在close。
这个close 和dispose什么区别呢？在该系列非托管中，Dispose不仅释放自己的资源，还干了一件事就是GC.SuppressFinalize(),也就是说去抑制终结器。
那么close没有去抑制终结器，所以区别还是挺大的。
而且在设计上，close 之后，还是可以open connect的，而dispose后不能open connect。close 是去释放现在占有的资源(相当于没收财产,加个死缓)，dispose是标记这个对象进入死亡阶段(死刑,一般来说救不回来了)。
异常保证
常说，通过try catch来捕获异常，万一真的出现没有捕获的异常怎么破？是不是应该做点啥？
处理异常实际上，需要三种保障。
1.基本保障。
2.强保证
3.no-throw 保障
分别介绍这三种不同的意思:
1.基本保证的要求是:确保异常离开产生该异常的函数后，程序中的资源不会泄露，而且所以对象处于有效状态。
2.强保证是在基本保证的前提下，他要求整个程序的状态不能因为某操作产生异常而变化。
3.no-throw 是程序不会发生异常。
那么这三种类型中，强保证是首推的。
单纯基本保证感觉又不够,no-throw 太严格，强保证是一种折中方案。
强保证规定:如果操作出现异常，那么应用程序状态必须和执行前操作是一样的，这样说比较诡异，简单点说是这样子的。
执行方法的操作要么是完全成功，要不是完全失败。如果失败，那么程序的状态就和执行操作之前一模一样，而不会出现部分成功的情况。
这不难想象到，如果我们调用一个方法出现了异常，如果方法中某一步出现异常，而数据发送了改变，但是剩余操作无法执行，这时候我们的程序数据将不可控。
那么这个时候我们如何去实现这个强类型保证呢？通过防御性的拷贝来实现，具体步骤如下:
1.先把要修改的数据拷贝一份。
2.在拷贝的数据上面修改，修改过程中，执行那些可能抛出异常的操作。
3.完全操作成功用拷贝文件去覆盖原数据。
这么一看，这不是cpu和内存损耗吗？
是的，但是这增加了程序的健壮性吗？随着时代的发展，分布式集群的发展，性能似乎可以用硬件来堆，程序的稳健性应该放在第一位。
我们是不是保证了强类型异常，那么是不是no-throw 永远用不到呢？其实提出3个标准的时候，是按照程序的严格顺序来的。强类型异常在异常下，无法继续执行了，但是数据不能部分修改。
那么no-throw用在什么地方呢?
下面几个地方一定不能出现异常。
1.finalizer 与 dispose中不能出现异常。
2.异常筛选器中不能出现异常。
3.委托目标中不能出现异常。
第一个在finalizer 中出现异常，那么线程会中断，可以想象一下终结器中断是啥子问题。
dispose中释放非托管中出现问题，资源问题即大问题，因为不好恢复。
异常筛选器中一旦出现异常，那么原先抛出的异常将会被新的异常覆盖，捕获不到原先的异常，就会出现艰难的错误处理问题。
委托目标这个很好理解了，多播委托中，一旦出现问题，那么后续的方法不会执行。
这个时候在任何可能出现异常的地方使用try catch，反复检查，捕获异常，从而不会中断程序。
结
这一章是对上一节的补充，还有很多细节是无法写完的,就到此吧，后续是一个自定义异常的例子。
以上只是个人整理，如有问题，请指出。最后卑微的说一句:跪求大佬指点 。
