精华内容
下载资源
问答
  • Java异常处理代码编写

    千次阅读 2019-08-19 10:12:38
    Java异常处理代码编写 java中的异常 在计算机程序运行的过程中,总是会出现各种各样的错误。 有一些错误是用户造成的,比如,希望用户输入一个int类型的年龄,但是用户的输入是abc: // 假设用户输入了abc: ...

    Java异常处理代码编写

    java中的异常

    在计算机程序运行的过程中,总是会出现各种各样的错误。

    有一些错误是用户造成的,比如,希望用户输入一个int类型的年龄,但是用户的输入是abc

    // 假设用户输入了abc:
    String s = "abc";
    int n = Integer.parseInt(s); // NumberFormatException!
    

    程序想要读写某个文件的内容,但是用户已经把它删除了:

    // 用户删除了该文件:
    String t = readFile("C:\\abc.txt"); // FileNotFoundException!
    

    还有一些错误是随机出现,并且永远不可能避免的。比如:

    • 网络突然断了,连接不到远程服务器;
    • 内存耗尽,程序崩溃了;
    • 用户点“打印”,但根本没有打印机;
    • ……

    所以,一个健壮的程序必须处理各种各样的错误。

    所谓错误,就是程序调用某个函数的时候,如果失败了,就表示出错。

    调用方如何获知调用失败的信息?有两种方法:

    方法一:约定返回错误码。

    例如,处理一个文件,如果返回0,表示成功,返回其他整数,表示约定的错误码:

    int code = processFile("C:\\test.txt");
    if (code == 0) {
        // ok:
    } else {
        // error:
        switch (code) {
        case 1:
            // file not found:
        case 2:
            // no read permission:
        default:
            // unknown error:
        }
    }
    

    因为使用int类型的错误码,想要处理就非常麻烦。这种方式常见于底层C函数。

    方法二:在语言层面上提供一个异常处理机制。

    Java内置了一套异常处理机制,总是使用异常来表示错误。

    异常是一种class,因此它本身带有类型信息。异常可以在任何地方抛出,但只需要在上层捕获,这样就和方法调用分离了:

    try {
        String s = processFile(“C:\\test.txt”);
        // ok:
    } catch (FileNotFoundException e) {
        // file not found:
    } catch (SecurityException e) {
        // no read permission:
    } catch (IOException e) {
        // io error:
    } catch (Exception e) {
        // other error:
    }
    

    因为Java的异常是class,它的继承关系如下:

                         ┌───────────┐
                         │  Object   │
                         └───────────┘
                               ▲
                               │
                         ┌───────────┐
                         │ Throwable │
                         └───────────┘
                               ▲
                     ┌─────────┴─────────┐
                     │                   │
               ┌───────────┐       ┌───────────┐
               │   Error   │       │ Exception │
               └───────────┘       └───────────┘
                     ▲                   ▲
             ┌───────┘              ┌────┴──────────┐
             │                      │               │
    ┌─────────────────┐    ┌─────────────────┐┌───────────┐
    │OutOfMemoryError │... │RuntimeException ││IOException│...
    └─────────────────┘    └─────────────────┘└───────────┘
                                    ▲
                        ┌───────────┴─────────────┐
                        │                         │
             ┌─────────────────────┐ ┌─────────────────────────┐
             │NullPointerException │ │IllegalArgumentException │...
             └─────────────────────┘ └─────────────────────────┘
    

    从继承关系可知:Throwable是异常体系的根,它继承自ObjectThrowable有两个体系:ErrorExceptionError表示严重的错误,程序对此一般无能为力,例如:

    • OutOfMemoryError:内存耗尽
    • NoClassDefFoundError:无法加载某个Class
    • StackOverflowError:栈溢出

    Exception则是运行时的错误,它可以被捕获并处理。

    某些异常是应用程序逻辑处理的一部分,应该捕获并处理。例如:

    • NumberFormatException:数值类型的格式错误
    • FileNotFoundException:未找到文件
    • SocketException:读取网络失败

    还有一些异常是程序逻辑编写不对造成的,应该修复程序本身。例如:

    • NullPointerException:对某个null的对象调用方法或字段
    • IndexOutOfBoundsException:数组索引越界

    Exception又分为两大类:

    1. RuntimeException以及它的子类;
    2. RuntimeException(包括IOExceptionReflectiveOperationException等等)

    Java规定:

    • 必须捕获的异常,包括Exception及其子类,但不包括RuntimeException及其子类,这种类型的异常称为Checked Exception。

    • 不需要捕获的异常,包括Error及其子类,RuntimeException及其子类。

    捕获异常

    捕获异常使用try...catch语句,把可能发生异常的代码放到try {...}中,然后使用catch捕获对应的Exception及其子类:

    // try...catch
    import java.io.UnsupportedEncodingException;
    import java.util.Arrays;
    
    public class Main {
        public static void main(String[] args) {
            byte[] bs = toGBK("中文");
            System.out.println(Arrays.toString(bs));
        }
    
        static byte[] toGBK(String s) {
            try {
                // 用指定编码转换String为byte[]:
                return s.getBytes("GBK");
            } catch (UnsupportedEncodingException e) {
                // 如果系统不支持GBK编码,会捕获到UnsupportedEncodingException:
                System.out.println(e); // 打印异常信息
                return s.getBytes(); // 尝试使用用默认编码
            }
        }
    }

    如果我们不捕获UnsupportedEncodingException,会出现编译失败的问题:

    编译器会报错,错误信息类似:unreported exception UnsupportedEncodingException; must be caught or declared to be thrown,并且准确地指出需要捕获的语句是return s.getBytes("GBK");。意思是说,像UnsupportedEncodingException这样的Checked Exception,必须被捕获。

    这是因为String.getBytes(String)方法定义是:

    public byte[] getBytes(String charsetName) throws UnsupportedEncodingException {
        ...
    }
    

    在方法定义的时候,使用throws Xxx表示该方法可能抛出的异常类型。调用方在调用的时候,必须强制捕获这些异常,否则编译器会报错。

    toGBK()方法中,因为调用了String.getBytes(String)方法,就必须捕获UnsupportedEncodingException。我们也可以不捕获它,而是在方法定义处用throws表示toGBK()方法可能会抛出UnsupportedEncodingException,就可以让toGBK()方法通过编译器检查:

    // try...catch
    import java.io.UnsupportedEncodingException;
    import java.util.Arrays;
    
    public class Main {
        public static void main(String[] args) {
            byte[] bs = toGBK("中文");
            System.out.println(Arrays.toString(bs));
        }
    
        static byte[] toGBK(String s) throws UnsupportedEncodingException {
            return s.getBytes("GBK");
        }
    }
    

    上述代码仍然会得到编译错误,但这一次,编译器提示的不是调用return s.getBytes("GBK");的问题,而是byte[] bs = toGBK("中文");。因为在main()方法中,调用toGBK(),没有捕获它声明的可能抛出的UnsupportedEncodingException

    修复方法是在main()方法中捕获异常并处理:

    // try...catch
    import java.io.UnsupportedEncodingException;
    import java.util.Arrays;
    
    public class Main {
        public static void main(String[] args) {
            try {
                byte[] bs = toGBK("中文");
                System.out.println(Arrays.toString(bs));
            } catch (UnsupportedEncodingException e) {
                System.out.println(e);
            }
        }
    
        static byte[] toGBK(String s) throws UnsupportedEncodingException {
            // 用指定编码转换String为byte[]:
            return s.getBytes("GBK");
        }
    }

    可见,只要是方法声明的Checked Exception,不在调用层捕获,也必须在更高的调用层捕获。所有未捕获的异常,最终也必须在main()方法中捕获,不会出现漏写try的情况。这是由编译器保证的。main()方法也是最后捕获Exception的机会。

    如果是测试代码,上面的写法就略显麻烦。如果不想写任何try代码,可以直接把main()方法定义为throws Exception

    public class Main {
        public static void main(String[] args) throws Exception {
            byte[] bs = toGBK("中文");
            System.out.println(Arrays.toString(bs));
        }
    
        static byte[] toGBK(String s) throws UnsupportedEncodingException {
            // 用指定编码转换String为byte[]:
            return s.getBytes("GBK");
        }
    }
    

    因为main()方法声明了可能抛出Exception,也就声明了可能抛出所有的Exception,因此在内部就无需捕获了。代价就是一旦发生异常,程序会立刻退出。

    还有一些童鞋喜欢在toGBK()内部“消化”异常:

    static byte[] toGBK(String s) {
        try {
            return s.getBytes("GBK");
        } catch (UnsupportedEncodingException e) {
            // 什么也不干
        }
        return null;
    

    这种捕获后不处理的方式是非常不好的,即使真的什么也做不了,也要先把异常记录下来:

    static byte[] toGBK(String s) {
        try {
            return s.getBytes("GBK");
        } catch (UnsupportedEncodingException e) {
            // 先记下来再说:
            e.printStackTrace();
        }
        return null;
    

    所有异常都可以调用printStackTrace()方法打印异常栈,这是一个简单有用的快速打印异常的方法。

    Java使用异常来表示错误,并通过try ... catch捕获异常;

    Java的异常是class,并且从Throwable继承;

    Error是无需捕获的严重错误,Exception是应该捕获的可处理的错误;

    RuntimeException无需强制捕获,非RuntimeException(Checked Exception)需强制捕获,或者用throws声明;

     

    捕获异常

    在Java中,凡是可能抛出异常的语句,都可以用try ... catch捕获。把可能发生异常的语句放在try { ... }中,然后使用catch捕获对应的Exception及其子类。

    多catch语句

    可以使用多个catch语句,每个catch分别捕获对应的Exception及其子类。JVM在捕获到异常后,会从上到下匹配catch语句,匹配到某个catch后,执行catch代码块,然后不再继续匹配。

    简单地说就是:多个catch语句只有一个能被执行。例如:

    public static void main(String[] args) {
        try {
            process1();
            process2();
            process3();
        } catch (IOException e) {
            System.out.println(e);
        } catch (NumberFormatException e) {
            System.out.println(e);
        }
    }
    

    存在多个catch的时候,catch的顺序非常重要:子类必须写在前面。例如:

    public static void main(String[] args) {
        try {
            process1();
            process2();
            process3();
        } catch (IOException e) {
            System.out.println("IO error");
        } catch (UnsupportedEncodingException e) { // 永远捕获不到
            System.out.println("Bad encoding");
        }
    }
    

    对于上面的代码,UnsupportedEncodingException异常是永远捕获不到的,因为它是IOException的子类。当抛出UnsupportedEncodingException异常时,会被catch (IOException e) { ... }捕获并执行。

    因此,正确的写法是把子类放到前面:

    public static void main(String[] args) {
        try {
            process1();
            process2();
            process3();
        } catch (UnsupportedEncodingException e) {
            System.out.println("Bad encoding");
        } catch (IOException e) {
            System.out.println("IO error");
        }
    }
    

    finally语句

    无论是否有异常发生,如果我们都希望执行一些语句,例如清理工作,怎么写?

    可以把执行语句写若干遍:正常执行的放到try中,每个catch再写一遍。例如:

    public static void main(String[] args) {
        try {
            process1();
            process2();
            process3();
            System.out.println("END");
        } catch (UnsupportedEncodingException e) {
            System.out.println("Bad encoding");
            System.out.println("END");
        } catch (IOException e) {
            System.out.println("IO error");
            System.out.println("END");
        }
    }
    

    上述代码无论是否发生异常,都会执行System.out.println("END");这条语句。

    那么如何消除这些重复的代码?Java的try ... catch机制还提供了finally语句,finally语句块保证有无错误都会执行。上述代码可以改写如下:

    public static void main(String[] args) {
        try {
            process1();
            process2();
            process3();
        } catch (UnsupportedEncodingException e) {
            System.out.println("Bad encoding");
        } catch (IOException e) {
            System.out.println("IO error");
        } finally {
            System.out.println("END");
        }
    }
    

    注意finally有几个特点:

    1. finally语句不是必须的,可写可不写;
    2. finally总是最后执行。

    如果没有发生异常,就正常执行try { ... }语句块,然后执行finally。如果发生了异常,就中断执行try { ... }语句块,然后跳转执行匹配的catch语句块,最后执行finally

    可见,finally是用来保证一些代码必须执行的。

    某些情况下,可以没有catch,只使用try ... finally结构。例如:

    void process(String file) throws IOException {
        try {
            ...
        } finally {
            System.out.println("END");
        }
    }
    

    因为方法声明了可能抛出的异常,所以可以不写catch

    捕获多种异常

    如果某些异常的处理逻辑相同,但是异常本身不存在继承关系,那么就得编写多条catch子句:

    public static void main(String[] args) {
        try {
            process1();
            process2();
            process3();
        } catch (IOException e) {
            System.out.println("Bad input");
        } catch (NumberFormatException e) {
            System.out.println("Bad input");
        } catch (Exception e) {
            System.out.println("Unknown error");
        }
    }
    

    因为处理IOExceptionNumberFormatException的代码是相同的,所以我们可以把它两用|合并到一起:

    public static void main(String[] args) {
        try {
            process1();
            process2();
            process3();
        } catch (IOException | NumberFormatException e) { // IOException或NumberFormatException
            System.out.println("Bad input");
        } catch (Exception e) {
            System.out.println("Unknown error");
        }
    }

    使用try ... catch ... finally时:

    • 多个catch语句的匹配顺序非常重要,子类必须放在前面;

    • finally语句保证了有无异常都会执行,它是可选的;

    • 一个catch语句也可以匹配多个非继承关系的异常。



    抛出异常

    异常的传播

    当某个方法抛出了异常时,如果当前方法没有捕获异常,异常就会被抛到上层调用方法,直到遇到某个try ... catch被捕获为止:

    public class Main {
        public static void main(String[] args) {
            try {
                process1();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    
        static void process1() {
            process2();
        }
    
        static void process2() {
            Integer.parseInt(null); // 会抛出NumberFormatException
        }
    }
    

    通过printStackTrace()可以打印出方法的调用栈,类似:

    java.lang.NumberFormatException: null
        at java.base/java.lang.Integer.parseInt(Integer.java:614)
        at java.base/java.lang.Integer.parseInt(Integer.java:770)
        at Main.process2(Main.java:16)
        at Main.process1(Main.java:12)
        at Main.main(Main.java:5)
    

    printStackTrace()对于调试错误非常有用,上述信息表示:NumberFormatException是在java.lang.Integer.parseInt方法中被抛出的,调用层次从上到下依次是:

    1. main()调用process1()
    2. process1()调用process2()
    3. process2()调用Integer.parseInt(String)
    4. Integer.parseInt(String)调用Integer.parseInt(String, int)

    查看Integer.java源码可知,抛出异常的方法代码如下:

    public static int parseInt(String s, int radix) throws NumberFormatException {
        if (s == null) {
            throw new NumberFormatException("null");
        }
        ...
    }
    

    并且,每层调用均给出了源代码的行号,可直接定位。

    抛出异常

    当发生错误时,例如,用户输入了非法的字符,我们就可以抛出异常。

    如何抛出异常?参考Integer.parseInt()方法,抛出异常分两步:

    1. 创建某个Exception的实例;
    2. throw语句抛出。

    下面是一个例子:

    void process2(String s) {
        if (s==null) {
            NullPointerException e = new NullPointerException();
            throw e;
        }
    }
    

    实际上,绝大部分抛出异常的代码都会合并写成一行:

    void process2(String s) {
        if (s==null) {
            throw new NullPointerException();
        }
    }
    

    如果一个方法捕获了某个异常后,又在catch子句中抛出新的异常,就相当于把抛出的异常类型“转换”了:

    void process1(String s) {
        try {
            process2();
        } catch (NullPointerException e) {
            throw new IllegalArgumentException();
        }
    }
    
    void process2(String s) {
        if (s==null) {
            throw new NullPointerException();
        }
    }
    

    process2()抛出NullPointerException后,被process1()捕获,然后抛出IllegalArgumentException()

    如果在main()中捕获IllegalArgumentException,我们看看打印的异常栈:

    public class Main {
        public static void main(String[] args) {
            try {
                process1();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    
        static void process1() {
            try {
                process2();
            } catch (NullPointerException e) {
                throw new IllegalArgumentException();
            }
        }
    
        static void process2() {
            throw new NullPointerException();
        }
    }
    

    打印出的异常栈类似:

    java.lang.IllegalArgumentException
        at Main.process1(Main.java:15)
        at Main.main(Main.java:5)
    

    这说明新的异常丢失了原始异常信息,我们已经看不到原始异常NullPointerException的信息了。

    为了能追踪到完整的异常栈,在构造异常的时候,把原始的Exception实例传进去,新的Exception就可以持有原始Exception信息。对上述代码改进如下:

    public class Main {
        public static void main(String[] args) {
            try {
                process1();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    
        static void process1() {
            try {
                process2();
            } catch (NullPointerException e) {
                throw new IllegalArgumentException(e);
            }
        }
    
        static void process2() {
            throw new NullPointerException();
        }
    }

    运行上述代码,打印出的异常栈类似:

    java.lang.IllegalArgumentException: java.lang.NullPointerException
        at Main.process1(Main.java:15)
        at Main.main(Main.java:5)
    Caused by: java.lang.NullPointerException
        at Main.process2(Main.java:20)
        at Main.process1(Main.java:13)
    

    注意到Caused by: Xxx,说明捕获的IllegalArgumentException并不是造成问题的根源,根源在于NullPointerException,是在Main.process2()方法抛出的。

    在代码中获取原始异常可以使用Throwable.getCause()方法。如果返回null,说明已经是“根异常”了。

    有了完整的异常栈的信息,我们才能快速定位并修复代码的问题。

    如果我们在try或者catch语句块中抛出异常,finally语句是否会执行?例如:

    public class Main {
        public static void main(String[] args) {
            try {
                Integer.parseInt("abc");
            } catch (Exception e) {
                System.out.println("catched");
                throw new RuntimeException(e);
            } finally {
                System.out.println("finally");
            }
        }
    }

    上述代码执行结果如下:

    catched
    finally
    Exception in thread "main" java.lang.RuntimeException: java.lang.NumberFormatException: For input string: "abc"
        at Main.main(Main.java:8)
    Caused by: java.lang.NumberFormatException: For input string: "abc"
        at ...
    

    第一行打印了catched,说明进入了catch语句块。第二行打印了finally,说明执行了finally语句块。

    因此,在catch中抛出异常,不会影响finally的执行。JVM会先执行finally,然后抛出异常。

    异常屏蔽

    如果在执行finally语句时抛出异常,那么,catch语句的异常还能否继续抛出?例如:

    public class Main {
        public static void main(String[] args) {
            try {
                Integer.parseInt("abc");
            } catch (Exception e) {
                System.out.println("catched");
                throw new RuntimeException(e);
            } finally {
                System.out.println("finally");
                throw new IllegalArgumentException();
            }
        }
    }
    

    执行上述代码,发现异常信息如下:

    catched
    finally
    Exception in thread "main" java.lang.IllegalArgumentException
        at Main.main(Main.java:11)
    

    这说明finally抛出异常后,原来在catch中准备抛出的异常就“消失”了,因为只能抛出一个异常。没有被抛出的异常称为“被屏蔽”的异常(Suppressed Exception)。

    在极少数的情况下,我们需要获知所有的异常。如何保存所有的异常信息?方法是先用origin变量保存原始异常,然后调用Throwable.addSuppressed(),把原始异常添加进来,最后在finally抛出:

    public class Main {
        public static void main(String[] args) throws Exception {
            Exception origin = null;
            try {
                System.out.println(Integer.parseInt("abc"));
            } catch (Exception e) {
                origin = e;
                throw e;
            } finally {
                Exception e = new IllegalArgumentException();
                if (origin != null) {
                    e.addSuppressed(origin);
                }
                throw e;
            }
        }
    }

    catchfinally都抛出了异常时,虽然catch的异常被屏蔽了,但是,finally抛出的异常仍然包含了它:

    Exception in thread "main" java.lang.IllegalArgumentException
        at Main.main(Main.java:11)
    Suppressed: java.lang.NumberFormatException: For input string: "abc"
        at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
        at java.base/java.lang.Integer.parseInt(Integer.java:652)
        at java.base/java.lang.Integer.parseInt(Integer.java:770)
        at Main.main(Main.java:6)
    

    通过Throwable.getSuppressed()可以获取所有的Suppressed Exception

    绝大多数情况下,在finally中不要抛出异常。因此,我们通常不需要关心Suppressed Exception

    调用printStackTrace()可以打印异常的传播栈,对于调试非常有用;

    捕获异常并再次抛出新的异常时,应该持有原始异常信息;

    通常不要在finally中抛出异常。如果在finally中抛出异常,应该原始异常加入到原有异常中。调用方可通过Throwable.getSuppressed()获取所有添加的Suppressed Exception

     

    自定义异常

    Java标准库定义的常用异常包括:

    Exception
    │
    ├─ RuntimeException
    │  │
    │  ├─ NullPointerException
    │  │
    │  ├─ IndexOutOfBoundsException
    │  │
    │  ├─ SecurityException
    │  │
    │  └─ IllegalArgumentException
    │     │
    │     └─ NumberFormatException
    │
    ├─ IOException
    │  │
    │  ├─ UnsupportedCharsetException
    │  │
    │  ├─ FileNotFoundException
    │  │
    │  └─ SocketException
    │
    ├─ ParseException
    │
    ├─ GeneralSecurityException
    │
    ├─ SQLException
    │
    └─ TimeoutException
    

    当我们在代码中需要抛出异常时,尽量使用JDK已定义的异常类型。例如,参数检查不合法,应该抛出IllegalArgumentException

    static void process1(int age) {
        if (age <= 0) {
            throw new IllegalArgumentException();
        }
    }
    

    在一个大型项目中,可以自定义新的异常类型,但是,保持一个合理的异常继承体系是非常重要的。

    一个常见的做法是自定义一个BaseException作为“根异常”,然后,派生出各种业务类型的异常。

    BaseException需要从一个适合的Exception派生,通常建议从RuntimeException派生:

    public class BaseException extends RuntimeException {
    }
    

    其他业务类型的异常就可以从BaseException派生:

    public class UserNotFoundException extends BaseException {
    }
    
    public class LoginFailedException extends BaseException {
    }
    
    ...
    

    自定义的BaseException应该提供多个构造方法:

    public class BaseException extends RuntimeException {
        public BaseException() {
            super();
        }
    
        public BaseException(String message, Throwable cause) {
            super(message, cause);
        }
    
        public BaseException(String message) {
            super(message);
        }
    
        public BaseException(Throwable cause) {
            super(cause);
        }
    }
    

    上述构造方法实际上都是原样照抄RuntimeException。这样,抛出异常的时候,就可以选择合适的构造方法。通过IDE可以根据父类快速生成子类的构造方法。

    抛出异常时,尽量复用JDK已定义的异常类型;

    自定义异常体系时,推荐从RuntimeException派生“根异常”,再派生出业务异常;

    自定义异常时,应该提供多种构造方法。

     

    断言

    断言(Assertion)是一种调试程序的方式。在Java中,使用assert关键字来实现断言。

    我们先看一个例子:

    public static void main(String[] args) {
        double x = Math.abs(-123.45);
        assert x >= 0;
        System.out.println(x);
    }
    

    语句assert x >= 0;即为断言,断言条件x >= 0预期为true。如果计算结果为false,则断言失败,抛出AssertionError

    使用assert语句时,还可以添加一个可选的断言消息:

    assert x >= 0 : "x must >= 0";
    

    这样,断言失败的时候,AssertionError会带上消息x must >= 0,更加便于调试。

    Java断言的特点是:断言失败时会抛出AssertionError,导致程序结束退出。因此,断言不能用于可恢复的程序错误,只应该用于开发和测试阶段。

    对于可恢复的程序错误,不应该使用断言。例如:

    void sort(int[] arr) {
        assert arr != null;
    }
    

    应该抛出异常并在上层捕获:

    void sort(int[] arr) {
        if (x == null) {
            throw new IllegalArgumentException("array cannot be null");
        }
    }
    

    当我们在程序中使用assert时,例如,一个简单的断言:

    public class Main {
        public static void main(String[] args) {
            int x = -1;
            assert x > 0;
            System.out.println(x);
        }
    }

    断言x必须大于0,实际上x-1,断言肯定失败。执行上述代码,发现程序并未抛出AssertionError,而是正常打印了x的值。

    这是怎么肥四?为什么assert语句不起作用?

    这是因为JVM默认关闭断言指令,即遇到assert语句就自动忽略了,不执行。

    要执行assert语句,必须给Java虚拟机传递-enableassertions(可简写为-ea)参数启用断言。所以,上述程序必须在命令行下运行才有效果:

    $ java -ea Main.java
    Exception in thread "main" java.lang.AssertionError
    	at Main.main(Main.java:5)
    

    还可以有选择地对特定地类启用断言,命令行参数是:-ea:com.itranswarp.sample.Main,表示只对com.itranswarp.sample.Main这个类启用断言。

    或者对特定地包启用断言,命令行参数是:-ea:com.itranswarp.sample...(注意结尾有3个.),表示对com.itranswarp.sample这个包启动断言。

    实际开发中,很少使用断言。更好的方法是编写单元测试,后续我们会讲解JUnit的使用。

    断言是一种调试方式,断言失败会抛出AssertionError,只能在开发和测试阶段启用断言;

    对可恢复的错误不能使用断言,而应该抛出异常;

    断言很少被使用,更好的方法是编写单元测试。

     

    JDK Logging

    在编写程序的过程中,发现程序运行结果与预期不符,怎么办?当然是用System.out.println()打印出执行过程中的某些变量,观察每一步的结果与代码逻辑是否符合,然后有针对性地修改代码。

    代码改好了怎么办?当然是删除没有用的System.out.println()语句了。

    如果改代码又改出问题怎么办?再加上System.out.println()

    反复这么搞几次,很快大家就发现使用System.out.println()非常麻烦。

    怎么办?

    解决方法是使用日志。

    那什么是日志?日志就是Logging,它的目的是为了取代System.out.println()

    输出日志,而不是用System.out.println(),有以下几个好处:

    1. 可以设置输出样式,避免自己每次都写"ERROR: " + var
    2. 可以设置输出级别,禁止某些级别输出。例如,只输出错误日志;
    3. 可以被重定向到文件,这样可以在程序运行结束后查看日志;
    4. 可以按包名控制日志级别,只输出某些包打的日志;
    5. 可以……

    总之就是好处很多啦。

    那如何使用日志?

    因为Java标准库内置了日志包java.util.logging,我们可以直接用。先看一个简单的例子:

    // logging
    import java.util.logging.Level;
    import java.util.logging.Logger;
    public class Hello {
        public static void main(String[] args) {
            Logger logger = Logger.getGlobal();
            logger.info("start process...");
            logger.warning("memory is running out...");
            logger.fine("ignored.");
            logger.severe("process will be terminated...");
        }
    }

    运行上述代码,得到类似如下的输出:

    Mar 02, 2019 6:32:13 PM Hello main
    INFO: start process...
    Mar 02, 2019 6:32:13 PM Hello main
    WARNING: memory is running out...
    Mar 02, 2019 6:32:13 PM Hello main
    SEVERE: process will be terminated...
    

    对比可见,使用日志最大的好处是,它自动打印了时间、调用类、调用方法等很多有用的信息。

    再仔细观察发现,4条日志,只打印了3条,logger.fine()没有打印。这是因为,日志的输出可以设定级别。JDK的Logging定义了7个日志级别,从严重到普通:

    • SEVERE
    • WARNING
    • INFO
    • CONFIG
    • FINE
    • FINER
    • FINEST

    因为默认级别是INFO,因此,INFO级别以下的日志,不会被打印出来。使用日志级别的好处在于,调整级别,就可以屏蔽掉很多调试相关的日志输出。

    使用Java标准库内置的Logging有以下局限:

    Logging系统在JVM启动时读取配置文件并完成初始化,一旦开始运行main()方法,就无法修改配置;

    配置不太方便,需要在JVM启动时传递参数-Djava.util.logging.config.file=<config-file-name>

    因此,Java标准库内置的Logging使用并不是非常广泛。更方便的日志系统我们稍后介绍。

    使用logger.severe()打印异常:

            Logger logger = Logger.getLogger(Main.class.getName());
            logger.info("Start process...");
            try {
                "".getBytes("invalidCharsetName");
            } catch (UnsupportedEncodingException e) {
                // TODO: 使用logger.severe()打印异常
            }
            logger.info("Process end.");
    

    日志是为了替代System.out.println(),可以定义格式,重定向到文件等;

    日志可以存档,便于追踪问题;

    日志记录可以按级别分类,便于打开或关闭某些级别;

    可以根据配置文件调整日志,无需修改代码;

    Java标准库提供了java.util.logging来实现日志功能。

     

    Commons Logging

    和Java标准库提供的日志不同,Commons Logging是一个第三方日志库,它是由Apache创建的日志模块。

    Commons Logging的特色是,它可以挂接不同的日志系统,并通过配置文件指定挂接的日志系统。默认情况下,Commons Loggin自动搜索并使用Log4j(Log4j是另一个流行的日志系统),如果没有找到Log4j,再使用JDK Logging。

    使用Commons Logging只需要和两个类打交道,并且只有两步:

    第一步,通过LogFactory获取Log类的实例; 第二步,使用Log实例的方法打日志。

    示例代码如下:

    import org.apache.commons.logging.Log;
    import org.apache.commons.logging.LogFactory;
    public class Main {
        public static void main(String[] args) {
            Log log = LogFactory.getLog(Main.class);
            log.info("start...");
            log.warn("end.");
        }
    }

    运行上述代码,肯定会得到编译错误,类似error: package org.apache.commons.logging does not exist(找不到org.apache.commons.logging这个包)。因为Commons Logging是一个第三方提供的库,所以,必须先把它下载下来。下载后,解压,找到commons-logging-1.2.jar这个文件,再把Java源码Main.java放到一个目录下,例如work目录:

    work
    │
    ├─ commons-logging-1.2.jar
    │
    └─ Main.java
    

    然后用javac编译Main.java,编译的时候要指定classpath,不然编译器找不到我们引用的org.apache.commons.logging包。编译命令如下:

    javac -cp commons-logging-1.2.jar Main.java
    

    如果编译成功,那么当前目录下就会多出一个Main.class文件:

    work
    │
    ├─ commons-logging-1.2.jar
    │
    ├─ Main.java
    │
    └─ Main.class
    

    现在可以执行这个Main.class,使用java命令,也必须指定classpath,命令如下:

    java -cp .;commons-logging-1.2.jar Main
    

    注意到传入的classpath有两部分:一个是.,一个是commons-logging-1.2.jar,用;分割。.表示当前目录,如果没有这个.,JVM不会在当前目录搜索Main.class,就会报错。

    如果在Linux或macOS下运行,注意classpath的分隔符不是;,而是:

    java -cp .:commons-logging-1.2.jar Main
    

    运行结果如下:

    Mar 02, 2019 7:15:31 PM Main main
    INFO: start...
    Mar 02, 2019 7:15:31 PM Main main
    WARNING: end.
    

    Commons Logging定义了6个日志级别:

    • FATAL
    • ERROR
    • WARNING
    • INFO
    • DEBUG
    • TRACE

    默认级别是INFO

    使用Commons Logging时,如果在静态方法中引用Log,通常直接定义一个静态类型变量:

    // 在静态方法中引用Log:
    public class Main {
        static final Log log = LogFactory.getLog(Main.class);
    
        static void foo() {
            log.info("foo");
        }
    }
    

    在实例方法中引用Log,通常定义一个实例变量:

    // 在实例方法中引用Log:
    public class Person {
        protected final Log log = LogFactory.getLog(getClass());
    
        void foo() {
            log.info("foo");
        }
    }
    

    注意到实例变量log的获取方式是LogFactory.getLog(getClass()),虽然也可以用LogFactory.getLog(Person.class),但是前一种方式有个非常大的好处,就是子类可以直接使用该log实例。例如:

    // 在子类中使用父类实例化的log:
    public class Student extends Person {
        void bar() {
            log.info("bar");
        }
    }
    

    由于Java类的动态特性,子类获取的log字段实际上相当于LogFactory.getLog(Student.class),但却是从父类继承而来,并且无需改动代码。

    此外,Commons Logging的日志方法,例如info(),除了标准的info(String)外,还提供了一个非常有用的重载方法:info(String, Throwable),这使得记录异常更加简单:

    try {
        ...
    } catch (Exception e) {
        log.error("got exception!", e);
    }

    Commons Logging是使用最广泛的日志模块;

    Commons Logging的API非常简单;

    Commons Logging可以自动检测并使用其他日志模块。

     

    Log4j

    前面介绍了Commons Logging,可以作为“日志接口”来使用。而真正的“日志实现”可以使用Log4j。

    Log4j是一种非常流行的日志框架,最新版本是2.x。

    Log4j是一个组件化设计的日志系统,它的架构大致如下:

    log.info("User signed in.");
     │
     │   ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
     ├──>│ Appender │───>│  Filter  │───>│  Layout  │───>│ Console  │
     │   └──────────┘    └──────────┘    └──────────┘    └──────────┘
     │
     │   ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
     ├──>│ Appender │───>│  Filter  │───>│  Layout  │───>│   File   │
     │   └──────────┘    └──────────┘    └──────────┘    └──────────┘
     │
     │   ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
     └──>│ Appender │───>│  Filter  │───>│  Layout  │───>│  Socket  │
         └──────────┘    └──────────┘    └──────────┘    └──────────┘
    

    当我们使用Log4j输出一条日志时,Log4j自动通过不同的Appender把同一条日志输出到不同的目的地。例如:

    • console:输出到屏幕;
    • file:输出到文件;
    • socket:通过网络输出到远程计算机;
    • jdbc:输出到数据库

    在输出日志的过程中,通过Filter来过滤哪些log需要被输出,哪些log不需要被输出。例如,仅输出ERROR级别的日志。

    最后,通过Layout来格式化日志信息,例如,自动添加日期、时间、方法名称等信息。

    上述结构虽然复杂,但我们在实际使用的时候,并不需要关心Log4j的API,而是通过配置文件来配置它。

    以XML配置为例,使用Log4j的时候,我们把一个log4j2.xml的文件放到classpath下就可以让Log4j读取配置文件并按照我们的配置来输出日志。下面是一个配置文件的例子:

    <?xml version="1.0" encoding="UTF-8"?>
    <Configuration>
    	<Properties>
            <!-- 定义日志格式 -->
    		<Property name="log.pattern">%d{MM-dd HH:mm:ss.SSS} [%t] %-5level %logger{36}%n%msg%n%n</Property>
            <!-- 定义文件名变量 -->
    		<Property name="file.err.filename">log/err.log</Property>
    		<Property name="file.err.pattern">log/err.%i.log.gz</Property>
    	</Properties>
        <!-- 定义Appender,即目的地 -->
    	<Appenders>
            <!-- 定义输出到屏幕 -->
    		<Console name="console" target="SYSTEM_OUT">
                <!-- 日志格式引用上面定义的log.pattern -->
    			<PatternLayout pattern="${log.pattern}" />
    		</Console>
            <!-- 定义输出到文件,文件名引用上面定义的file.err.filename -->
    		<RollingFile name="err" bufferedIO="true" fileName="${file.err.filename}" filePattern="${file.err.pattern}">
    			<PatternLayout pattern="${log.pattern}" />
    			<Policies>
                    <!-- 根据文件大小自动切割日志 -->
    				<SizeBasedTriggeringPolicy size="1 MB" />
    			</Policies>
                <!-- 保留最近10份 -->
    			<DefaultRolloverStrategy max="10" />
    		</RollingFile>
    	</Appenders>
    	<Loggers>
    		<Root level="info">
                <!-- 对info级别的日志,输出到console -->
    			<AppenderRef ref="console" level="info" />
                <!-- 对error级别的日志,输出到err,即上面定义的RollingFile -->
    			<AppenderRef ref="err" level="error" />
    		</Root>
    	</Loggers>
    </Configuration>
    

    虽然配置Log4j比较繁琐,但一旦配置完成,使用起来就非常方便。对上面的配置文件,凡是INFO级别的日志,会自动输出到屏幕,而ERROR级别的日志,不但会输出到屏幕,还会同时输出到文件。并且,一旦日志文件达到指定大小(1MB),Log4j就会自动切割新的日志文件,并最多保留10份。

    有了配置文件还不够,因为Log4j也是一个第三方库,我们需要从这里下载Log4j,解压后,把以下3个jar包放到classpath中:

    • log4j-api-2.x.jar
    • log4j-core-2.x.jar
    • log4j-jcl-2.x.jar

    因为Commons Logging会自动发现并使用Log4j,所以,把上一节下载的commons-logging-1.2.jar也放到classpath中。

    要打印日志,只需要按Commons Logging的写法写,不需要改动任何代码,就可以得到Log4j的日志输出,类似:

    03-03 12:09:45.880 [main] INFO  com.itranswarp.learnjava.Main
    Start process...
    

    最佳实践

    在开发阶段,始终使用Commons Logging接口来写入日志,并且开发阶段无需引入Log4j。如果需要把日志写入文件, 只需要把正确的配置文件和Log4j相关的jar包放入classpath,就可以自动把日志切换成使用Log4j写入,无需修改任何代码。

    通过Commons Logging实现日志,不需要修改代码即可使用Log4j 使用Log4j只需要把log4j2.xml和相关jar放入classpath 如果要更换Log4j,只需要移除log4j2.xml和相关jar 只有扩展Log4j时,才需要引用Log4j的接口(例如,将日志加密写入数据库的功能,需要自己开发)

     

    SLF4J和Logback

    前面介绍了Commons Logging和Log4j这一对好基友,它们一个负责充当日志API,一个负责实现日志底层,搭配使用非常便于开发。

    有的童鞋可能还听说过SLF4J和Logback。这两个东东看上去也像日志,它们又是啥?

    其实SLF4J类似于Commons Logging,也是一个日志接口,而Logback类似于Log4j,是一个日志的实现。

    为什么有了Commons Logging和Log4j,又会蹦出来SLF4J和Logback?

    这是因为Java有着非常悠久的开源历史,不但OpenJDK本身是开源的,而且我们用到的第三方库,几乎全部都是开源的。

    开源生态丰富的一个特定就是,同一个功能,可以找到若干种互相竞争的开源库。

    因为对Commons Logging的接口不满意,有人就搞了SLF4J。因为对Log4j的性能不满意,有人就搞了Logback。

    我们先来看看SLF4J对Commons Logging的接口有何改进。

    在Commons Logging中,我们要打印日志,有时候得这么写:

    int score = 99;
    p.setScore(score);
    log.info("Set score " + score + " for Person " + p.getName() + " ok.");
    

    拼字符串是一个非常麻烦的事情,所以SLF4J的日志接口改进成这样了:

    int score = 99;
    p.setScore(score);
    logger.info("Set score {} for Person {} ok.", score, p.getName());
    

    我们靠猜也能猜出来,SLF4J的日志接口传入的是一个带占位符的字符串,用后面的变量自动替换占位符,所以看起来更加自然。

    如何使用SLF4J?它的接口实际上和Commons Logging几乎一模一样:

    import org.slf4j.Logger;
    import org.slf4j.LoggerFactory;
    
    class Main {
        final Logger logger = LoggerFactory.getLogger(getClass());
    }
    

    对比一下Commons Logging和SLF4J的接口:

    Commons LoggingSLF4J
    org.apache.commons.logging.Logorg.slf4j.Logger
    org.apache.commons.logging.LogFactoryorg.slf4j.LoggerFactory

    不同之处就是Log变成了Logger,LogFactory变成了LoggerFactory。

    使用SLF4J和Logback和前面讲到的使用Commons Logging加Log4j是类似的,先分别下载SLF4JLogback,然后把以下jar包放到classpath下:

    • slf4j-api-1.7.x.jar
    • logback-classic-1.2.x.jar
    • logback-core-1.2.x.jar

    然后使用SLF4J的Logger和LoggerFactory即可。和Log4j类似,我们仍然需要一个Logback的配置文件,把logback.xml放到classpath下,配置如下:

    <?xml version="1.0" encoding="UTF-8"?>
    <configuration>
    
    	<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
    		<encoder>
    			<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
    		</encoder>
    	</appender>
    
    	<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    		<encoder>
    			<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
    			<charset>utf-8</charset>
    		</encoder>
    		<file>log/output.log</file>
    		<rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
    			<fileNamePattern>log/output.log.%i</fileNamePattern>
    		</rollingPolicy>
    		<triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
    			<MaxFileSize>1MB</MaxFileSize>
    		</triggeringPolicy>
    	</appender>
    
    	<root level="INFO">
    		<appender-ref ref="CONSOLE" />
    		<appender-ref ref="FILE" />
    	</root>
    </configuration>
    

    运行即可获得类似如下的输出:

    13:15:25.328 [main] INFO  com.itranswarp.learnjava.Main - Start process...
    

    从目前的趋势来看,越来越多的开源项目从Commons Logging加Log4j转向了SLF4J加Logback。

    SLF4J和Logback可以取代Commons Logging和Log4j;

    始终使用SLF4J的接口写入日志,使用Logback只需要配置,不需要修改代码。

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    展开全文
  • 主要为大家详细介绍了java简单自定义异常实例代码,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
  • Java异常处理简单实例

    千次阅读 2019-05-12 16:56:35
    Java异常处理 异常是程序中的一些错误,但并不是所有的错误都是异常,并且错误有时候是可以避免的。 比如说,你的代码少了一个分号,那么运行出来结果是提示是错误 java.lang.Error;如果你用System.out.println...

    Java异常处理

    异常是程序中的一些错误,但并不是所有的错误都是异常,并且错误有时候是可以避免的。

    比如说,你的代码少了一个分号,那么运行出来结果是提示是错误 java.lang.Error;如果你用System.out.println(11/0),那么你是因为你用0做了除数,会抛出 java.lang.ArithmeticException 的异常。

    异常发生的原因有很多,通常包含以下几大类:

    • 用户输入了非法数据。
    • 要打开的文件不存在。
    • 网络通信时连接中断,或者JVM内存溢出。

    这些异常有的是因为用户错误引起,有的是程序错误引起的,还有其它一些是因为物理错误引起的。-

    要理解Java异常处理是如何工作的,你需要掌握以下三种类型的异常:

    • 检查性异常:最具代表的检查性异常是用户错误或问题引起的异常,这是程序员无法预见的。例如要打开一个不存在文件时,一个异常就发生了,这些异常在编译时不能被简单地忽略。
    • 运行时异常: 运行时异常是可能被程序员避免的异常。与检查性异常相反,运行时异常可以在编译时被忽略。
    • 错误: 错误不是异常,而是脱离程序员控制的问题。错误在代码中通常被忽略。例如,当栈溢出时,一个错误就发生了,它们在编译也检查不到的。

    Java异常体系结构

    Java把异常当作对象来处理,并定义一个基类java.lang.Throwable作为所有异常的超类。在Java API中已经定义了许多异常类,这些异常类分为两大类,错误Error和异常Exception

    问题

    编程实现输入一个正整数,求该数的阶乘的程序。要求能捕获输入数字格式异常(NumberFormatException),即当输入字符不是正整数时,能出现提示信息“输入数据格式不对,请重新输入一个正整数”。

     

    代码

    package training8;
    
    import java.util.InputMismatchException;
    import java.util.Scanner;
    
    public class MutilTest {
    
    	public static void main(String[] args) {
    		// TODO Auto-generated method stub
    		System.out.println("请输入一个正整数:");
    		Scanner sc=new Scanner(System.in);
    		int n=-1;
    		long sum=1;
    		try {
    			n=sc.nextInt();
    		} catch (Exception e) {
    			// TODO: handle exception
    			System.out.println("输入数据格式不对,请重新输入一个正整数\n");
    		}
    		//n=sc.nextInt();
    		sc.close();
    		if(n!=-1)
    		{
    		for(int i=1;i<=n;i++)
    			sum*=i;
    		 System.out.printf("%d!=%d",n,sum);
    		}
    		sc.close();
    		}
    
    }
    

    运行结果

     

    展开全文
  • 在程序设计中,进行异常处理是非常关键和重要的一部分。一个程序的异常处理框架的好坏直接影响到整个项目的代码质量以及后期维护成本和难度。
  • Java异常处理

    千次阅读 2018-07-25 20:25:50
    处理反馈、业务异常代码错误 在开发业务系统中,我们目前绝大多数采用MVC模式,但是往往有人把service跟controller紧紧的耦合在一起, 甚至直接使用Threadlocal来隐式传值,并且复杂的逻辑几乎只能使用service中存储...

    处理反馈、业务异常、代码错误

    在开发业务系统中,我们目前绝大多数采用MVC模式,但是往往有人把service跟controller紧紧的耦合在一起,

    甚至直接使用Threadlocal来隐式传值,并且复杂的逻辑几乎只能使用service中存储的全局对象来传递处理结果,

    包括异常.这样一来首先有违MVC模式,二来逻辑十分不清晰,难以维护。

    常常面临着这样的问题:

    • 系统运行出错,但是完全不知道错误发生的位置.
    • 我们找到了错误的位置,但是完全不知道是因为什么.
    • 系统明明出了错误,但是就是看不到错误堆栈信息.

    理由:

    经常看到一些项目,在全局定义一个 AppException,然后所有地方都只抛出这个异常,并且把捕获的异常case到这个AppException中.会有如下问题:

    • 浪费log日志存储空间,并且栈顶并不是最接近发生异常的代码位置.
    • 只有一种异常类,无法精准区分开异常类型
    • 异常类后期难以修改以增加其携带的信息.

     

    需要手动处理异常:

    • 你有能力处理异常,并且你知道如何处理
    • 你有责任处理异常

     

    自定义业务异常

         -考虑如下场景: 系统提供一个API,用于修改用户信息,服务器端采用json数据交互.

         -首先我们定义ServiceException,用来表示业务逻辑受理失败,它仅表示我们处理业务的时候发现无法继续执行下去.

    一个业务系统不可能不对用户提交的数据进行验证,验证包括两方面 : 有效性合法性,

    • 有效性: 比如用户所在岗位,是否属于数据库有记录的岗位ID,如果不存在,无效.
    • 合法性: 比如用户名只允许输入最多12个字符,用户提交了20个字符,不合法.

    合法性检查,可以交给java的校验框架执行,比如JSR303.

    1. 要修改的用户ID不存在.
    2. 用户被锁定,不允许修改.
    3. 乐观锁机制发现用户已经被被人修改过.

    对于前3种,我们认为是有效性检查失败,

    1. 由于某种原因,我们的程序无法保存到数据库.<属于我们无法处理的异常>
    2. 一些程序员错误的开发了代码,导致保存过程中出现异常,比如NPE.<程序员bug.>

     

    现在的问题是,前三种情况我们如何通知用户呢?

    1. 在controller 调用userService的checkUserExist()方法.
    2. 在controller直接书写业务逻辑.
    3. 在service响应一个状态码机制,比如1 2 3表示错误信息,0 表示没有任何错误.

    显然前2种方法都不可取 ,因为MVC设计模式告诉我们,controller是用来接收页面参数,并且调用逻辑处理,最后组织页面响应的地方.我们不可以在controller进行逻辑处理,controller只应该负责用户API入口和响应的处理(如若不然,思考一下如果有一天service的代码打包成jar放到另一个平台,没有controller了,该怎么办?)

    状态码机制是个不错的选择,可是如此一来,用户保存逻辑变了,比如增加一个情况,不允许修改已经离职的用户,那么我们还需要修改controller的代码,代码量增加,维护成本增高,并且还耦合了service,不符合MVC设计模式.

     

    这样一来只要我们检查到不允许保存的项目,我们就可以直接throw 一个新的异常,异常机制会帮助我们中断代码执行.

    接下来有2种选择:

    1. 在controller 使用try-catch进行处理.

         第1种方式是不可取的 ,注意我们抛出的ServiceException,它仅仅逻辑处理异常,并且我们的方法前面没有声明throws ServiceException,这表示他是一个非受查异常.controller也没有关心会发生什么异常.

         为什么不定义成受查异常呢? 如果是一个受查异常,那么意味着controller必须要处理你的异常.并且如果有一天你的业务逻辑变了,可能多一种检查项,就需要增加一个异常,反之需要删除一个异常,那么你的方法签名也需要改变,controller也随之要改变,这又变成了紧耦合,这和用状态码123表示处理结果没有什么不同.

         我们可以为每一种检查项定义一个异常吗? 可以,但是那样显得太多余了.因为业务逻辑处理失败的时候,根据我们需求,我们只需要通知用户失败的原因(通常应该是一段字符串),以及服务器受理失败的一个状态码(有时可能不需要状态码,这要看你的设计了),这样这需要一个包含原因属性的异常即可满足我们需求.

         2.直接把异常抛给上层框架统一处理.

          最后我们决定这个异常继承自RuntimeException.并且包含一个接受一个错误原因的构造器,这样controller层也不需要知道异常,只要全局捕获到ServiceException做统一的处理即可,这无论是在struct1,2时代,还是springMVC中,甚至servlet年代,都是极为容易的!

    自定义异常不提供无参构造器 ,因为绝对不允许你抛出一个逻辑处理异常,但是不指明原因,想想看,你是必须要告诉用户为什么受理失败的!

     

    注意一点,在这个类中,我们定义了2个log对象,分别指向 ServiceException.class 和 ModuleControllerAdvice.class . 并且处理 ServiceException的时候使用了info级别的日志输出,这是很有用的.

    • 首先,ServiceException一定要和其他的代码错误分离,不应该混为一谈.
    • 其次,ServiceException并不一定要记录日志,我们应该提供独立的log对象,方便开关.

    接下来你可以在修改用户的时候想客户端响应这样的JSON

    如此一来没有任何地方需要关心异常,或者业务逻辑校验失败的情况.用户也可以得到很友好的错误提示.

    如何对异常进行分类

    如果你只需要一句概括,那么直接定义一个简单的异常,用于中断处理,并且与用户保持友好交互即可.

    如果不可能一句话描述清楚,并且包含附加信息,比如需要在日志或者数据库记录消息ID,此时可能专门针对这种重要/复杂业务创建独立异常.

    上述两种情况因为web系统,是用户发起请求之后需要等待程序给予响应结果的.

     

     

    如果是后台作业,或者复杂业务需要追溯性.这种通常用流程判断语句控制,要用异常处理.我们认为这些流程判断一定在一个原子性处理中.并且检查到(不是遇到)的问题(不是异常)需要记录到用户可友好查看的日志.这种情况属于处理反馈,并不叫异常.

    综上,笔者通常分为如下几类:

    1. 逻辑异常,这类异常用于描述业务无法按照预期的情况处理下去,属于用户制造的意外.
    2. 代码错误,这类异常用于描述开发的代码错误,例如NPE,ILLARG,都属于程序员制造的BUG.
    3. 专有异常,多用于特定业务场景,用于描述指定作业出现意外情况无法预先处理.

    各类异常必须要有单独的日志记录,或者分级,分类可管理.有的时候仅仅想给三方运维看到逻辑异常.

    业务逻辑检查,也是意外情况

    UnknownHostException,表示找不到这样的主机,这个异常和NoUserException有什么区别么?

    换言之,没有这样的主机是异常,没有这样的用户不是异常了么?

    所以一定要弄明白什么是用异常来控制逻辑,什么是定义程序异常.

    异常处理效率很低

    书中所示的例子,是在循环中大量使用try-catch进行检查,但是业务系统,用户发起请求的次数与该场景天壤地别.淘宝的11`11是个很好的反例.但是请你的系统上到这个级别再考虑这种问题.

    1. 系统有千万并发,不可能还去考虑这些中规中矩的按部就班的方式,别忘了MVC本来就浪费很多资源,代码量增加很多.
    2. 业务系统也存在很多巨量任务处理的情况.但是那些任务都是原子性的,现在MVC中的controller和service可不是原子性的,不然为什么要区分这么多层呢.
    3. 如果那么在乎效率,考虑下重写Throwable的fillStackTrace方法.你要知道异常的开销大到底大在什么地方,fillStackTrace是一个native方法,会填充异常类内部的运行轨迹.

    上述代码就是典型的使用异常来处理业务逻辑.这种方式需要严重的禁止!

    上述代码最大的问题在于,我们如何利用异常来自动处理事务呢?

    然而这和我们的异常中断service没有什么冲突.也并不是一回事.

    • 我们提倡在 业务处理 的时候,如果发现无法处理直接抛出异常即可.
    • 而并不是在 逻辑处理 的时候,用异常来判断逻辑进行的状况.

    最后俏皮一句:微服务横行的今天,我们在action里面直接写业务处理,也无可厚非.

     

    展开全文
  • 简单 Java图片加水印,支持旋转和透明度设置 摘要:Java源码,文件操作,图片水印 util实现Java图片水印添加功能,有添加图片水印和文字水印,可以设置水印位置,透明度、设置对线段锯齿状边缘处理、水印图片的路径,...
  • JAVA异常处理最佳实战心得

    千次阅读 2018-09-28 16:42:12
    尤其是在各种服务相关的代码中,可能正常业务逻辑的代码量很少,大部分都是各种try catch处理各种异常代码,因为实际中异常情况很多,为了保证服务的健壮与稳定性,要尽可能考虑与处理掉各种异常情况。所以在java...

    项目github地址:bitcarmanlee easy-algorithm-interview-and-practice
    欢迎大家star,留言,一起学习进步

    1.异常分类

    异常Exception是Java中非常常用的功能,它可以简化代码,并且增强代码的安全性。尤其是在各种服务相关的代码中,可能正常业务逻辑的代码量很少,大部分都是各种try catch处理各种异常的代码,因为实际中异常情况很多,为了保证服务的健壮与稳定性,要尽可能考虑与处理掉各种异常情况。所以在java中遇到大段大段的try catch也就不足为奇。

    在这里插入图片描述
    (图片来自网络)

    从上面的图可以看出来,
    1.Throwable是所有异常的根,java.lang.Throwable
    2.Throwable包括Error与Exception两个子类。
    3.Error类一般是指与虚拟机相关的问题,如系统崩溃,虚拟机错误,内存空间不足,方法调用栈溢出等。如java.lang.StackOverFlowError和Java.lang.OutOfMemoryError。对于这类错误,Java编译器不去检查他们,编译器也没法提前发现。对于这类错误导致的应用程序中断,仅仅靠程序本身是无法恢复与预防的。所以对于Error,一般是程序直接终止停止运行。
    4.Exception类为程序可以处理的异常。遇到这种类型的异常,一般在代码中会去做相关处理,并且让程序恢复运行,而不是直接让程序终止运行。

    2.Runtime Exception 与 Checked Exception

    Runtime Exception一般表示虚拟机层面操作中可能遇到的异常,是一种常见运行时错误。运行时异常在代码中不一定要求捕获或者抛出。
    常见的RuntimeException
    1.NullPointerException NullPointerException是开发中最常见的UncheckedException,尤其实在代码调试阶段。如果在一个空指针上引用方法或变量或对象等,编译器编译的时候不会报错,但是运行期会抛出NullPointerException。
    2.ArithmeticException 算术运算异常 最常见的为除数为0
    3.IllegalArgumentException 传递非法参数异常
    4. IndexOutOfBoundsException 下标越界异常 这个我们在处理各种数组,集合的时候也经常遇到。
    在这里插入图片描述

    Checked exceptions与runtime exception的目的不尽相同。Checked exception一般用来指示一种调用方能够直接处理的异常情况。而runtime exception一般是虚拟机层面的问题,代表一种调用方本身无法处理或恢复的程序错误。
    checked exceptions意味着不在程序的即时控制内的错误场景。它们通常与外部资源/网络资源交互,例如数据库问题、网络连接错误、丢失文件等。程序中经常要处理各种资源文件,所以像FileNotFoundException这种异常就很常见。FileNotFoundException的继承关系如下图。
    在这里插入图片描述

    3.异常处理的基本方法

    Java的异常处理本质上是抛出异常和捕获异常。
    抛出异常:要理解抛出异常,首先要明白什么是异常情形(exception condition),它是指阻止当前方法或作用域继续执行的问题。其次把异常情形和普通问题相区分,普通问题是指在当前环境下能得到足够的信息,总能处理这个错误。对于异常情形,已经无法继续下去了,因为在当前环境下无法获得必要的信息来解决问题,你所能做的就是从当前环境中跳出,并把问题提交给上一级环境,这就是抛出异常时所发生的事情。抛出异常后,会有几件事随之发生。首先,是像创建普通的java对象一样将使用new在堆上创建一个异常对象;然后,当前的执行路径(已经无法继续下去了)被终止,并且从当前环境中弹出对异常对象的引用。此时,异常处理机制接管程序,并开始寻找一个恰当的地方继续执行程序,这个恰当的地方就是异常处理程序或者异常处理器,它的任务是将程序从错误状态中恢复,以使程序要么换一种方式运行,要么继续运行下去。
    捕获异常:在方法抛出异常之后,运行时系统将转为寻找合适的异常处理器(exception handler)。潜在的异常处理器是异常发生时依次存留在调用栈中的方法的集合。当异常处理器所能处理的异常类型与方法抛出的异常类型相符时,即为合适的异常处理器。运行时系统从发生异常的方法开始,依次回查调用栈中的方法,直至找到含有合适异常处理器的方法并执行。当运行时系统遍历调用栈而未找到合适的异常处理器,则运行时系统终止。同时,意味着Java程序的终止。

    对于运行时异常、错误和检查异常,Java技术所要求的异常处理方式有所不同。

    由于运行时异常及其子类的不可查性,为了更合理、更容易地实现应用程序,Java规定,运行时异常将由Java运行时系统自动抛出,允许应用程序忽略运行时异常。

    对于方法运行中可能出现的Error,当运行方法不欲捕捉时,Java允许该方法不做任何抛出声明。因为,大多数Error异常属于永远不能被允许发生的状况,也属于合理的应用程序不该捕捉的异常。

    对于所有的检查异常,Java规定:一个方法必须捕捉,或者声明抛出方法之外。也就是说,当一个方法选择不捕捉检查异常时,它必须声明将抛出异常。
    (此部分内容来自参考文献1)

    4.异常处理常见的样例

    与异常处理相关的关键字有如下几个:try,catch,finally,throw,throws。所有异常的处理都围绕这几个字展开。
    try: 用于监听,判断try代码块中的内容是否有异常。如果发生异常,将会被跑出来。
    catch: 捕获try代码块中的相关异常。
    finally: finally 关键字用来创建在 try 代码块后面执行的代码块。无论是否发生异常,finally 代码块中的代码总会被执行。在 finally 代码块中,可以运行清理类型等收尾善后性质的语句。比如关闭数据库连接、断开网络连接和关闭磁盘文件等。
    throw: 用来抛出异常。
    throws: 如果一个方法没有捕获到一个检查性异常,那么该方法必须使用 throws 关键字来声明,用在方法签名中。

    4.1 try-catch方式捕获异常

    这种是最常见的处理异常的方式。一般的用法如下:

    try{
        //do something and might generate some exceptions    
    }catch(Exception e1){
        //handling exception1
    }catch(Exception e2){
        //handling exception2
    }
    

    如果抛出的异常对象属于catch子句的异常类,或者属于该异常类的子类,则认为生成的异常对象与catch块捕获的异常类型相匹配。
    如果有多重catch,整体的原则为:先catch住子类,再catch父类,层层递进。

    举个例子:

    try{
        //code open a file
    }catch(FileNotFoundException e1){
        //handling e1
    }catch(IOException e2){
        //handling e2
    }catch(Exception e3){
        //handling e3
    }
    

    4.2 try-catch-finally方式捕获异常

    这种方式也很常见。与上面唯一的区别在于多了一个finally部分用来处理一些售后工作。

    try{
        //code open a file
    }catch(FileNotFoundException e1){
        //handling e1
    }catch(IOException e2){
        //handling e2
    }catch(Exception e3){
        //handling e3
    }finally(){
        //close the file
    }
    

    4.3 方法中throw出异常

    上面的方式,我们都是去捕获系统抛出的异常,当然我们也可以抛出来异常。在实际项目中,我们经常自己定义各种异常,方便快速定位与查找系统异常。
    自己抛出异常也非常简单

    throw ThrowableObject
    

    只需要抛出一个Throwable的对象即可。比如我们经常用类似的方法这么做:

    public class TestThrow extends Exception {
    
        public static class SomeException extends Exception {
            // nothing to do
        }
    
        public static void main(String[] args) {
            try {
                throw new SomeException();
            } catch (SomeException ex) {
                ex.printStackTrace();
            }
        }
    }
    

    先定义一个名为SomeException的类,该类继承自Exception。然后在逻辑中先抛出这个异常再catch住。
    注意throw是在函数内。

    4.4 throws

    如果一个方法可以导致一个异常,但是在这个方法内我们不想处理,想交给他的调用者去处理,这个时候可以采用throws的方式。要做到这点,我们可以在方法声明中包含一个throws子句。一个throws子句列举了一个方法可能引发的所有异常类型,可以包括多个异常。

    例如我们经常写的mapreduce程序里,mapper阶段的map方法就throws出来有两个异常:

      protected void map(KEYIN key, VALUEIN value, 
                         Context context) throws IOException, InterruptedException {
        context.write((KEYOUT) key, (VALUEOUT) value);
      }
    

    所以我们每次重写map方法的时候,也会throws出这两个异常。
    注意throws是在方法签名中,而不是在方法内部!

    5.throw与throws的区别

    throw语句在方法体内,标识抛出异常,有方法体内的语句来处理。一旦执行到throw语句,说明肯定要抛出异常,程序执行完throw语句之后立即停止;throw后面的任何语句不被执行,最邻近的try块用来检查它是否含有一个与异常类型匹配的catch语句。如果发现了匹配的块,控制转向该语句;如果没有发现,次包围的try块来检查,以此类推。如果没有发现匹配的catch块,默认异常处理程序中断程序的执行并且打印堆栈轨迹。
    throws语句在方法签名中,主要是声明这个方法会抛出这种类型的异常,使它的调用者知道要捕获这个异常。只是说该方法有可能要抛出某些异常。

    6.finally中不要改变返回值

    finally子句是可选项,可以有也可以没有。但是每个try语句至少需要一个catch或者finally子句。
    如果try里面有个return语句,try 后的 finally{} 里的 code 会在方法返回调用者前被执行。
    什么意思呢?总结起来一句话:在finally中改变返回值的做法是不好的。因为如果存在finally代码块,try中的return语句不会立马返回调用者,而是记录下返回值待finally代码块执行完毕之后再向调用者返回其值,然后如果在finally中修改了返回值,就会返回修改后的值。显然,在finally中返回或者修改返回值会对程序造成很大的困扰。
    看两个例子:

    public static int test() {
        int result = 0;
        try {
            result = 1;
            return result;
        } catch (Exception e) {
            result = 2;
            return result;
        } finally {
            result = 3;
        }
    }
    

    上面这段代码,方法的返回值是1。

    public class TestFinally extends Exception {
        public static class Person {
            public String name;
            public Person(String name) {
                this.name = name;
            }
        }
    
        public static Person test() {
            Person person = new Person("lili");
            try {
                person.name = "mm";
                return person;
            } catch (Exception ex) {
                return person;
            } finally {
                person.name = "yy";
            }
        }
    
        public static void main(String[] args) {
            Person person = test();
            System.out.println(person.name);
        }
    }
    

    以上代码输出为yy!

    如果finally中没有return语句,但是改变了要返回的值,这里有点类似与引用传递和值传递的区别,分以下两种情况,:

    1)如果return的数据是基本数据类型或文本字符串,则在finally中对该基本数据的改变不起作用,try中的return语句依然会返回进入finally块之前保留的值。

    2)如果return的数据是引用数据类型,而在finally中对该引用数据类型的属性值的改变起作用,try中的return语句返回的就是在finally中改变后的该属性的值。

    不管怎么说,在finally中返回或者修改返回值都不是一件好事情,墙裂建议大家不这么干。

    参考文献:
    1.https://www.cnblogs.com/Qian123/p/5715402.html#_label2
    2.https://blog.csdn.net/Next_Second/article/details/73090994

    展开全文
  • Java学习-详谈Java异常异常处理

    千次阅读 2020-09-13 17:14:17
    1、异常 1.1异常概念 异常,就是不正常的意思。在生活中:医生说,你的身体某个部位有异常,该部位和正常相比有点不同,该部位的...Java处理异常的方式是中断处理。 2、异常体系 2.1Throwable类 异常的根类: java.lang.T
  • java 异常处理机制

    2015-11-04 20:53:33
    java异常处理机制 java的异常处理机制可以让程序具有极好的容错性吗,让程序更加健壮。实现将业务功能处理代码和异常处理代码分离,提供更好的可读性。java把所有的非正常情况分为两种,一种是Error,一种是...
  • java 异常分类和处理机制

    万次阅读 多人点赞 2018-06-01 15:08:26
    Java语言中的异常处理机制就解决的上述问题,把错误与异常的管理带到了面向对象的世界 Java语言定义了很多异常类,将运行错误和异常的信息和处理方法封装在了异常类中,帮助程序员检查和控制异常。即J.....
  • Java 异常类及异常处理简单概念

    千次阅读 2016-11-19 13:13:49
    异常也称为例外,是在程序运行过程中发生的、会打断程序正常执行的事件,下面是几种常见的异常: 1. 算术异常( ArithmeticException)。...当异常发生时,通常可以用两种方法来处理,一种是交由 Java 默认
  • 简单说说Java中的异常处理机制的简单原理和应用 异常指Java程序运行时(非编译)所发生的非正常情况或错误; 所有异常的根类为java.lang.Throwable; Throwable派生了2个子类:Error和Exception 异常机制可以使程序...
  • 如何处理java异常

    千次阅读 2018-07-03 16:07:43
    我们目前绝大多数采用MVC模式,但是往往有人把service跟controller紧紧的耦合在一起,甚至直接使用Threadlocal来隐式传值,并且复杂的逻辑几乎只能使用service中存储的全局对象来传递处理结果,包括异常。...
  • 高效的Java异常处理框架

    千次阅读 2017-03-14 22:02:50
    高效的Java异常处理框架 摘要:本文从Java异常最基本的概念、语法开始讲述了Java异常处理的基本知识,分析了Java异常体系结构,对比Spring的异常处理框架,阐述了异常处理的基本原则。并且作者提出了自己处理一...
  • Java异常处理终结篇——如何进行Java异常处理设计

    万次阅读 多人点赞 2014-02-28 15:08:57
    使用Java异常的人很多,但能合理使用的却不多,Java异常处理设计是一个冷门的话题,但好的异常设计会让程序有质的变化,所以本文从各个方面分析便总结了,在Java程序中,如何进行异常设计。
  • 第一次想到分享自己的所学,也记录一下自己程序员的历程吧~~~ 这次实现的是学习中遇到的简易计算机(一共有三个文件...通过输入要运算的两个数再按想要运算的运算符即可在第三个文本框显示结果,并且附有两个异常处理
  • Java异常处理总结

    2016-12-19 23:09:33
    Java异常处理总结    异常处理是程序设计中一个非常重要的方面,也是程序设计的一大难点,从C开始,你也许已经知道如何用if...else...来控制异常了,也许是自发的,然而这种控制异常痛苦,同一个异常或者...
  • java异常的捕获及处理

    万次阅读 多人点赞 2019-03-16 15:28:13
    一、Java异常简介 什么是异常? 程序运行时,发生的不被期望的事件,它阻止了程序按照...异常处理机制能让程序在异常发生时,按照代码的预先设定的异常处理逻辑,针对性地处理异常,让程序尽最大可能恢复正常并继续...
  • Java异常处理最佳实践

    千次阅读 2019-06-30 18:38:55
    Java处理异常并不是一个简单的事情。不仅仅初学者很难理解,即使一些有经验的开发者也需要花费很多时间来思考如何处理异常,包括需要处理哪些异常,怎样处理等等。这也是绝大多数开发团队都会制定一些规则来...
  • java异常处理机制详解

    万次阅读 2016-08-24 14:35:19
    Java异常处理主要依赖于try,catch,finally,throws,throw这五个关键字。下面分别介绍它们:
  • java异常分类,异常处理,面试中常见异常问题!

    千次阅读 多人点赞 2019-05-14 13:03:06
    Throwable 类是 Java 语言中所有错误或异常的超类。提供了错误堆栈实现等一系列方法。 有两个直接子类:Error & Exception 程序错误一般分为三种: 1.编译错误;2.运行时错误;3.逻辑错误。 (1)编译错误是因为...
  • 谈谈你对Java异常处理机制的理解 先谈谈我的理解:异常处理机制可以说是让我们编写的程序运行起来更加的健壮,无论是在程序调试、运行期间发生的异常情况的捕获,都提供的有效的补救动作,任何业务...
  • JAVA 异常处理

    千次阅读 热门讨论 2020-10-31 17:19:59
    异常由来:问题也是现实生活中一个具体的事物,也可以通过java的类的形式进行描述。并封装成对象。其实就是java对不正常情况进行描述后的对象体现。 对于问题的划分(两种):一种是严重的问题,一种是非严重的问题...
  • 当APP出现Java异常、native异常和ANR时需要重启当前APP。 解决方案: 使用爱奇艺的xCrash框架进行捕获并重启。 xCrash GitHub地址: https://github.com/iqiyi/xCrash/blob/master/README.zh-CN.md 步骤一: 在...
  • Java异常处理的几种方法

    千次阅读 2020-10-31 22:18:10
    Java中所有异常的父类是Throwable类,在Throwable类下有两大子类: 一个是Error类,指系统错误异常,例如:VirtualMachineError 虚拟机错误,ThreadDeath 线程死锁。一般如果是Error类的异常的话,就是程序的硬伤,...
  • java 事务异常处理

    千次阅读 2019-06-15 16:15:52
    java 事务异常处理 问题称述 ​ 一次在开发过程中,我需要用到事务;由于工程架构规则导致不能按照常用的事务处理方式。 Controller层代码示例 @RequestMapping(value = "/api/abc",metabchod=RequestMethod.POST) ...
  • Java异常处理机制的简单原理和应用

    千次阅读 2017-07-10 11:17:27
    异常是指Java程序运行时所发生的非正常情况或者错误,就像人们正常生活发生...可以 用一个对象来表示,Java采用面向对象的方式来处理异常,把程序中发生的每个异常都封装到一个对象来表 示, 该对象里面包含有异常信息
  • 异常一般表示程序运行过程中遇到的一些错误,这可能是代码本身的语法逻辑错误,也可能是JVM本身的物理原因导致,异常的触发会导致程序的终止。为了更好地了解异常,我们先来看一下API: Throwable是所有异常的超类...
  • Java异常处理机制

    万次阅读 多人点赞 2018-09-22 18:58:55
    一、什么是java异常java异常指在程序运行时可能出现的一些错误,如:文件找不到、网络连接失败、非法参数等。异常是一个事件,它发生在程序运行期间,中断了正在执行的程序的正常指令流。Java通过API中Throwable...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 389,670
精华内容 155,868
关键字:

java异常处理简单代码

java 订阅