我知道的是：在哪里调用就在哪里抛出异常。其余基本都是抛出啊。。。。。
哎。
9 个解决方案
#1
看需求，需要在本级处理的就try catch，需要交给上级处理的就throw
#2
你也说的真笼统……就好比，有错误就改，没错误就好！
#3
原则是你能处理就要先处理了，你仔细考虑过处理不了就抛出去，然后让其它使用你方法的人自己处理，你只用告诉别人我这抛出了一个异常你要处理。大概就这样
#4
在service中进行业务处理时,进行一些增删改操作时,就需要对异常进行捕获 try {}catch(){},其他的可以进行抛出,或不处理
#5
您好，提问者：
下面给出一种数学异常：
try{
int a = 2 / 0;
}catch(Exception e){
System.out.println("0不能当除数...");
}
再给你String转int类型一种转换异常：
try{
int a = Integer.parseInt("123s");//这个字符串包含字母了，字母是无法转换为数字的.
}catch(Exception e){
System.out.println("int转为String出错...");
}
还有就是其他常见IO异常等处理。
try catch把异常信息捕获了，用户体验更友好，程序更健壮， 如果方法不捕获就 throw抛出交给上层方法处理。
关于空指针异常： 建议直接做if为空的条件判断，不需要捕获异常。
下面给出一种数学异常：
try{
int a = 2 / 0;
}catch(Exception e){
System.out.println("0不能当除数...");
}
再给你String转int类型一种转换异常：
try{
int a = Integer.parseInt("123s");//这个字符串包含字母了，字母是无法转换为数字的.
}catch(Exception e){
System.out.println("int转为String出错...");
}
还有就是其他常见IO异常等处理。
try catch把异常信息捕获了，用户体验更友好，程序更健壮， 如果方法不捕获就 throw抛出交给上层方法处理。
关于空指针异常： 建议直接做if为空的条件判断，不需要捕获异常。
#6
一般是外层捕获，内层抛出吧。
#7
一个原则，当你的层需要跟外部分割开的时候，你就该catch。
比如，service和dao层，在大部分情况下，dao服务于service，但这都属于开发组内部，所以，dao直接throw就可以了。
但是到了service层，调用service的是另外的开发小组（比如客户端小组），从架构上来说，就需要隐藏代码的内部细节，这个时候就必须要catch掉，然后该写日志写日志，改重新封装错误重新封装。
完毕~
比如，service和dao层，在大部分情况下，dao服务于service，但这都属于开发组内部，所以，dao直接throw就可以了。
但是到了service层，调用service的是另外的开发小组（比如客户端小组），从架构上来说，就需要隐藏代码的内部细节，这个时候就必须要catch掉，然后该写日志写日志，改重新封装错误重新封装。
完毕~
#8
一般我是这样干，底层不处理，往上抛，上层去try catch
然后去处理对应异常类型。再根据需求展示给用户。
然后去处理对应异常类型。再根据需求展示给用户。
#9
我觉得如果出现exception要做特殊处理就用try catch，比如我做的项目要求批量导入客户数据，数据库记录的手机号不能重复，而且导完要收集重复的数据反馈给操作者，如果每次插表前读一次数据库，操作太大了，因为批量导入一次可能几千。
直接给表建unique key，在spring框架有个DuplicateKeyException，插入重复数据就会进入这个exception，catch里面可以提取这条记录的数据用于反馈。
直接给表建unique key，在spring框架有个DuplicateKeyException，插入重复数据就会进入这个exception，catch里面可以提取这条记录的数据用于反馈。
#1
看需求，需要在本级处理的就try catch，需要交给上级处理的就throw
#2
你也说的真笼统……就好比，有错误就改，没错误就好！
#3
原则是你能处理就要先处理了，你仔细考虑过处理不了就抛出去，然后让其它使用你方法的人自己处理，你只用告诉别人我这抛出了一个异常你要处理。大概就这样
#4
在service中进行业务处理时,进行一些增删改操作时,就需要对异常进行捕获 try {}catch(){},其他的可以进行抛出,或不处理
#5
您好，提问者：
下面给出一种数学异常：
try{
int a = 2 / 0;
}catch(Exception e){
System.out.println("0不能当除数...");
}
再给你String转int类型一种转换异常：
try{
int a = Integer.parseInt("123s");//这个字符串包含字母了，字母是无法转换为数字的.
}catch(Exception e){
System.out.println("int转为String出错...");
}
还有就是其他常见IO异常等处理。
try catch把异常信息捕获了，用户体验更友好，程序更健壮， 如果方法不捕获就 throw抛出交给上层方法处理。
关于空指针异常： 建议直接做if为空的条件判断，不需要捕获异常。
下面给出一种数学异常：
try{
int a = 2 / 0;
}catch(Exception e){
System.out.println("0不能当除数...");
}
再给你String转int类型一种转换异常：
try{
int a = Integer.parseInt("123s");//这个字符串包含字母了，字母是无法转换为数字的.
}catch(Exception e){
System.out.println("int转为String出错...");
}
还有就是其他常见IO异常等处理。
try catch把异常信息捕获了，用户体验更友好，程序更健壮， 如果方法不捕获就 throw抛出交给上层方法处理。
关于空指针异常： 建议直接做if为空的条件判断，不需要捕获异常。
#6
一般是外层捕获，内层抛出吧。
#7
一个原则，当你的层需要跟外部分割开的时候，你就该catch。
比如，service和dao层，在大部分情况下，dao服务于service，但这都属于开发组内部，所以，dao直接throw就可以了。
但是到了service层，调用service的是另外的开发小组（比如客户端小组），从架构上来说，就需要隐藏代码的内部细节，这个时候就必须要catch掉，然后该写日志写日志，改重新封装错误重新封装。
完毕~
比如，service和dao层，在大部分情况下，dao服务于service，但这都属于开发组内部，所以，dao直接throw就可以了。
但是到了service层，调用service的是另外的开发小组（比如客户端小组），从架构上来说，就需要隐藏代码的内部细节，这个时候就必须要catch掉，然后该写日志写日志，改重新封装错误重新封装。
完毕~
#8
一般我是这样干，底层不处理，往上抛，上层去try catch
然后去处理对应异常类型。再根据需求展示给用户。
然后去处理对应异常类型。再根据需求展示给用户。
#9
我觉得如果出现exception要做特殊处理就用try catch，比如我做的项目要求批量导入客户数据，数据库记录的手机号不能重复，而且导完要收集重复的数据反馈给操作者，如果每次插表前读一次数据库，操作太大了，因为批量导入一次可能几千。
直接给表建unique key，在spring框架有个DuplicateKeyException，插入重复数据就会进入这个exception，catch里面可以提取这条记录的数据用于反馈。
直接给表建unique key，在spring框架有个DuplicateKeyException，插入重复数据就会进入这个exception，catch里面可以提取这条记录的数据用于反馈。