8 个解决方案
#1
可以记录日志,分析用户操作中遇到的不稳定因素,一些比较隐藏的bug可能会被发现
#2
没太懂你的意思,我估计下面的东东能帮到你。
罗列多个catch,执行时一旦进入某个catch,其余catch不会被执行。
罗列多个catch,执行时一旦进入某个catch,其余catch不会被执行。
try {
int i = 1, j = 1;
Console.WriteLine(1 / (i - j));
}
catch (*Exception ex)
{
Console.Write("*Exception" + ex.Message);
}
catch (IOException ex)
{
Console.Write("IOException" + ex.Message);
}
catch (Exception ex)
{
Console.Write("Exception" + ex.Message);
}
#3
异常捕获就是希望当程序出现异常时,由开发人员决定此异常影不影响程序的正常运行
而且很多时候,开发人员会主动抛出一些异常
客户要求到这么牛逼,相信对于开发也是有所了解,甚至客户本身就是对方的开发对接人员,如果你觉得到处都写一样的try catch太傻逼了,那你可以通过全局异常捕获,统一处理所有你未捕获的异常,并在那里对异常分类处理
而且很多时候,开发人员会主动抛出一些异常
客户要求到这么牛逼,相信对于开发也是有所了解,甚至客户本身就是对方的开发对接人员,如果你觉得到处都写一样的try catch太傻逼了,那你可以通过全局异常捕获,统一处理所有你未捕获的异常,并在那里对异常分类处理
#4
每个函数写多个catch太麻烦了,既然你都知道会有什么异常发生,那就采用判断而不用去做相应的catch处理。
一般框架有问题就直接抛除去就行了,由外面去做异常处理,框架要是做异常处理后没有将异常的原始堆栈抛出去,其实对于客户端调试和判断问题带来不便。
一般框架有问题就直接抛除去就行了,由外面去做异常处理,框架要是做异常处理后没有将异常的原始堆栈抛出去,其实对于客户端调试和判断问题带来不便。
#5
#6
客户的确是有10年经验的开发人员,而我只刚毕业一年而已,所以领导要求我必须听客户意见
#7
#8
千万不要捕获ArgumentNullException,出现这些异常,说明你的应用逻辑出现问题,这些错误是可以开发时候避免的。
个人认为不是所有的异常都要捕获,例如对于Socket类来说,还没有Bind,就去Accept,结果抛出一个InvalidOperationException,这是说明你使用Socket类的方式错误,类的作者通过异常这种方式告诉你:该看看文档了。但是有些异常,例如SockeException,在进行任何数据发送的时候都有可能出现,我把这类异常理解为运行时异常,这类异常必须要处理。
另外,有些时候你可能无法在代码中处理一些异常,这样需要你把异常继续往Stack上扔,留给更上层的用户处理。
当然还有许多的细节问题,例如Stack错乱,自定义异常等等,需要你看看书
个人认为不是所有的异常都要捕获,例如对于Socket类来说,还没有Bind,就去Accept,结果抛出一个InvalidOperationException,这是说明你使用Socket类的方式错误,类的作者通过异常这种方式告诉你:该看看文档了。但是有些异常,例如SockeException,在进行任何数据发送的时候都有可能出现,我把这类异常理解为运行时异常,这类异常必须要处理。
另外,有些时候你可能无法在代码中处理一些异常,这样需要你把异常继续往Stack上扔,留给更上层的用户处理。
当然还有许多的细节问题,例如Stack错乱,自定义异常等等,需要你看看书
#1
可以记录日志,分析用户操作中遇到的不稳定因素,一些比较隐藏的bug可能会被发现
#2
没太懂你的意思,我估计下面的东东能帮到你。
罗列多个catch,执行时一旦进入某个catch,其余catch不会被执行。
罗列多个catch,执行时一旦进入某个catch,其余catch不会被执行。
try {
int i = 1, j = 1;
Console.WriteLine(1 / (i - j));
}
catch (*Exception ex)
{
Console.Write("*Exception" + ex.Message);
}
catch (IOException ex)
{
Console.Write("IOException" + ex.Message);
}
catch (Exception ex)
{
Console.Write("Exception" + ex.Message);
}
#3
异常捕获就是希望当程序出现异常时,由开发人员决定此异常影不影响程序的正常运行
而且很多时候,开发人员会主动抛出一些异常
客户要求到这么牛逼,相信对于开发也是有所了解,甚至客户本身就是对方的开发对接人员,如果你觉得到处都写一样的try catch太傻逼了,那你可以通过全局异常捕获,统一处理所有你未捕获的异常,并在那里对异常分类处理
而且很多时候,开发人员会主动抛出一些异常
客户要求到这么牛逼,相信对于开发也是有所了解,甚至客户本身就是对方的开发对接人员,如果你觉得到处都写一样的try catch太傻逼了,那你可以通过全局异常捕获,统一处理所有你未捕获的异常,并在那里对异常分类处理
#4
每个函数写多个catch太麻烦了,既然你都知道会有什么异常发生,那就采用判断而不用去做相应的catch处理。
一般框架有问题就直接抛除去就行了,由外面去做异常处理,框架要是做异常处理后没有将异常的原始堆栈抛出去,其实对于客户端调试和判断问题带来不便。
一般框架有问题就直接抛除去就行了,由外面去做异常处理,框架要是做异常处理后没有将异常的原始堆栈抛出去,其实对于客户端调试和判断问题带来不便。
#5
没太懂你的意思,我估计下面的东东能帮到你。
罗列多个catch,执行时一旦进入某个catch,其余catch不会被执行。try {[/quote
int i = 1, j = 1;
Console.WriteLine(1 / (i - j));
}
catch (*Exception ex)
{
Console.Write("*Exception" + ex.Message);
}
catch (IOException ex)
{
Console.Write("IOException" + ex.Message);
}
catch (Exception ex)
{
Console.Write("Exception" + ex.Message);
}
比如这些catch都是返回false,那么还有必要写这么多catch么?只写一个Exception异常不就行了么?
#6
异常捕获就是希望当程序出现异常时,由开发人员决定此异常影不影响程序的正常运行
而且很多时候,开发人员会主动抛出一些异常
客户要求到这么牛逼,相信对于开发也是有所了解,甚至客户本身就是对方的开发对接人员,如果你觉得到处都写一样的try catch太傻逼了,那你可以通过全局异常捕获,统一处理所有你未捕获的异常,并在那里对异常分类处理
客户的确是有10年经验的开发人员,而我只刚毕业一年而已,所以领导要求我必须听客户意见
#7
没太懂你的意思,我估计下面的东东能帮到你。
罗列多个catch,执行时一旦进入某个catch,其余catch不会被执行。try {[/quote
int i = 1, j = 1;
Console.WriteLine(1 / (i - j));
}
catch (*Exception ex)
{
Console.Write("*Exception" + ex.Message);
}
catch (IOException ex)
{
Console.Write("IOException" + ex.Message);
}
catch (Exception ex)
{
Console.Write("Exception" + ex.Message);
}
比如这些catch都是返回false,那么还有必要写这么多catch么?只写一个Exception异常不就行了么?
你不是要捕获三种异常,针对不同的异常进行不同的处理麽?!
#8
千万不要捕获ArgumentNullException,出现这些异常,说明你的应用逻辑出现问题,这些错误是可以开发时候避免的。
个人认为不是所有的异常都要捕获,例如对于Socket类来说,还没有Bind,就去Accept,结果抛出一个InvalidOperationException,这是说明你使用Socket类的方式错误,类的作者通过异常这种方式告诉你:该看看文档了。但是有些异常,例如SockeException,在进行任何数据发送的时候都有可能出现,我把这类异常理解为运行时异常,这类异常必须要处理。
另外,有些时候你可能无法在代码中处理一些异常,这样需要你把异常继续往Stack上扔,留给更上层的用户处理。
当然还有许多的细节问题,例如Stack错乱,自定义异常等等,需要你看看书
个人认为不是所有的异常都要捕获,例如对于Socket类来说,还没有Bind,就去Accept,结果抛出一个InvalidOperationException,这是说明你使用Socket类的方式错误,类的作者通过异常这种方式告诉你:该看看文档了。但是有些异常,例如SockeException,在进行任何数据发送的时候都有可能出现,我把这类异常理解为运行时异常,这类异常必须要处理。
另外,有些时候你可能无法在代码中处理一些异常,这样需要你把异常继续往Stack上扔,留给更上层的用户处理。
当然还有许多的细节问题,例如Stack错乱,自定义异常等等,需要你看看书