Io流在什么情况下用throws什么情况下用try catch?

工具类 最好是throws   如果是正式使用的话 需要try catch

这要看你的类是干什么用的如果是工具类 需要其他类来调用使用的话最好是throws如果是正式使用的话 肯定需要try catch

1. public class A
   
2. {
   
3. public void method1 throws Excetpion
   
4. {
   
5. //可能有一个SQLException
   
6. }
   
7. }
   
8. //调用类捕获异常
   
9. public class B
   
10. {
    
11. private A a;
    
12. try
    
13. {
    
14. a.method1();
    
15. }
    
16. catch(Exception e)
    
17. {
    
18. System.out.println(e);
    
19. }
    
20. 
    
21. }
    

复制代码

异常处理的原则

1、如果无法处理某个异常，那就不要捕获它。
2、如果捕获了一个异常，请不要胡乱处理它。
3、尽量在靠近异常被抛出的地方捕获异常。
4、在捕获异常的地方将它记录到日志中，除非您打算将它重新抛出。
5、按照您的异常处理必须多精细来构造您的方法。
6、需要用几种类型的异常就用几种，尤其是对于应用程序异常。   

java异常可以分成两大类：Exception和RuntimeException(虽然RuntimeException是从Exception继承的)。exception异常代表“无法避免的异常” 如io异常 往往这类异常是由于外部原因造成的，程序本身无法保证他们不发生，所以这类异常必须捕获。如果在函数内部无法处理这个异常必须再次抛出（在函数后面用throws语句），如果什么都不做就出现编译错误。
runtimexception是指“可以避免的异常”，如 null引用异常，这类异常都是由程序内部原因造成的，是可以避免的。对于这类异常可以忽略他们，但一旦发生程序就会异常终止。这类异常对debug非常有帮助，当然，如果需要也可以catch

理论上讲，应该捕捉一切可以预知的异常。当然，如果不是最终的使用者（客户程序员），而是类库提供者，可以throws，因为你可以确知这些异常会最终被处理；否则，一定要谨慎的使用throws，因为可能最终exception不会被正确处理。

的确是有这样的特例的。比如，在jsp里，即使不处理异常也不抛出，因为jsp本身机制，也不会报编译错。这个时候，可能会使这个异常成为类似于RuntimeException的东西，让最终用户看到。这种做法是不负责任的。

RuntimeException只是一个概念，实际上，本来所有的Exception都一样，本质上RuntimeException不会另行处理。所以，是不是throws，还是要根据你的总体设计中bean所处的地位来进行判断。


一句话总结：

除非你想把异常处理的责任交给调用者，一般不用throws, 。

解释：
比如你要读入一些文件，如果你想通知调用者，让调用者决定如何
处理这个异常，你就把这个异常throws给调用者；
如果你知道应该如何处理这个异常，或者你想把异常马上解决，
你可以就地catch她。

这完全取决于你想把异常自己立即处理还是想把处理责任返回给调用者。
取决于你的程序的结构和要求。

我的经验，大多是抛出后，被一级调用者处理，如果一级调用者再次抛出
此异常给二级调用者，很容易使问题复杂化；另外，还有一种情况就是
立即catch
高效处理Java异常的两种方法
按照Java语言的定义，所谓异常（Exception）指的就是向调用方法（calling method）表示发生非正常情况的习惯方式。本文讨论两种在处理异常时可兹利用的技术：异常嵌套和捕获适当的异常。

异常嵌套

你在试图捕获异常并打算扔出异常时该采取什么措施呢？同时，你希望原始的异常信息可用吗？

要回答以上的问题你不妨尝试一下NestedException类。具体的编程并不难，唯一要做的无非是利用构造器并且重载printStackTrace()以便显示出正确的数据。

此外，你还应当考虑封装Throwable而非Exception类来创建更具有重用性的组件。之后，你可以创建NestedRuntimeException变量封装Throwable但无需对其进行声明。清单A显示了完整的示例。

捕获适当的异常
正确地处理异常并不是一项轻松的任务，这是因为异常的处理有时会导致程序出现其他不明行为。不过，以下三条规则可以帮助你避免错误处理异常所可能遭遇的风险。

规则 #1: 总是捕获扔出异常的类型而不要理睬异常的超类。 清单B中的代码片断以示例的方式从错误编码和正确编码两个角度进行了说明。

为了遵守通常的代码习惯，你可以采用Exception类的大写字母作为变量名，如下所示：
catch(FileNotFoundException fnfe)

以及
catch(SQLException sqle)

规则 # 2: 决不让catch块留空。在很多情况下虽然确实编写了try/catch块但在代码的catch部分却什么都没有做。或者，如果采用了日志API（Logging API），那么请编写代码把异常写到日志中。

清单C 显示了以上编码的错误方式和正确方式。

规则 # 3: 决不扔出Exception基类的实例。开发人员应当总是扔出自己创建的异常类。

扔出异常的API很难处理。在声明方法扔出java.lang.Exception的情况下，清单A中所有的问题都会强加在API用户的头上，这样他们就无法以一种专业的编程方式来处理异常。通过为扔出API声明Exception类的子类这一举措，API开发人员就可以减轻用户的负担。

在IO流中，大部分时候涉及到的异常是IOException，在调用例如FileReader中的read方法的时候我们是使用了已经编写好的程序，而为了让调用时知道可能会发生异常，所以在编写时会抛出异常来告知调用者。

如果一直抛出的话，会抛给最终调用者，也就是抛给调用的客户，而客户是没有解决方法的，所以需要在抛给虚拟机之前做出一个解决方案，比如主函数中建立对象调用FileReader类时，也就是使用try，catch。

而如果我们要自定义一个类似于FileReader，写一个也拥有FileReader中read等方法的类时，我们需要以后的调用者知道，将有可能发生异常，这时候我们就需要抛出，而不是自己解决。