让我们来看一段有问题的代码：

handler.sendMessageDelayed(msg, -1);

这个方法的作用是延迟一段时间之后，发送一条消息。其中第一个参数msg是要发送的消息，第二个参数是延时的时间，单位是ms，按理来讲这个延时的时间必须大于等于0。但是万一其他人在调用的时候将这个参数传进去一个负数，比如-1，如果是你，你会怎么处理这种情况？

我们的代码在运行的过程当中，难免会出现一些错误，有开发人员人为导致的问题，比如除数为0，传进来一个空指针，或者某个人的年龄被设置为了负数，有些是外部原因，比如正在读取某个文件的时候，这个文件被删了，或者服务器给了你一个不存在的链接。

采取哪种错误处理方式，取决于错误的产生原因和严重程度。

采用默认值

用我们刚才的例子来举例，handler.sendMessageDelayed的第二个参数不能为负数，但是如果为负数，源码当中是这么处理的：

public final boolean sendMessageDelayed(Message msg, long delayMillis) {
    if (delayMillis < 0) {
        delayMillis = 0;
    }
    return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}

把小于0的输入，都当做0来处理。这是一种非常实用的处理方式。我们平时就经常用到这种方式，只是可能没有留意而已，比如SharedPreferences：

sharedPreferences.getString("username", "");

在获取数据的时候，如果失败，则返回一个默认值，而不是null，会使得你的程序更加健壮并且更加优雅。所以不要把第二个参数设置为null，因为如果设置为null的话，接下来又要有一个是否为null的判断，白费了这个方法的设计者这样设计的苦心。

断言

Java提供了断言机制，采用assert关键字。

assert s != null;

断言就像是“活的”注释，它告诉我们程序运行到这个地方的时候，应该处于什么样的状态，或是满足什么样的条件。
需要特别说明一下，如果你在Android Studio中使用assert关键字，IDE会建议你这样使用：

if (BuildConfig.DEBUG && s == null) throw new AssertionError();

因为用assert关键字来断言有个缺陷，就是无论你是在Debug版本还是Release版本当中，这些断言都无可避免的会被执行，而如果我们采用了上面的写法，在Release版本中，这些断言就不会存在了。
此外，Google的Guava库当中，也有一些用来起到类似断言功能的方法，推荐大家使用。

Preconditions.checkNotNull();
Preconditions.checkArgument();
Preconditions.checkElementIndex();
Preconditions.checkState();
Preconditions.checkPositionIndex();
Preconditions.checkPositionIndexes();

运行时异常

在这里，有一种情况需要特别注意一下：

Thread thread = new Thread();
thread.start();
thread.start();

我们都知道，一个线程是不能启动两次的，如果开发人员启动了两次，这种错误该如何处理？

程序员在编程过程当中人为导致的错误，所以应该抛出运行时异常。实际上android源码当中是这样处理这个问题的：

public synchronized void start() {
    if (hasBeenStarted) {
         throw new IllegalThreadStateException("Thread already started");
    }

    ...
}

针对这类问题，对应的解决办法应该是避免多次启动。

所有的运行时异常都应该从根源上去避免这个错误，而不是用try-catch代码块来捕获这个异常。

忽略

有人可能会这么处理刚才线程被启动两次的问题：

public synchronized void start() {
    if (hasBeenStarted) {
        return;
    }

    ...
}

如果这个线程已经被启动，则返回，什么都不做。这种做法有一定的缺陷，它在一定程度上放任了开发人员犯错误，同时它也有好处，我们来看另外一个例子：

public void close() throws IOException {
    synchronized (closeLock) {
        if (closed) {
            return;
        }
        closed = true;
    }
    ...
}

FileOutputStream的close方法就是这么做的，它忽略了多次调用。如果有两种情况下，都需要关闭流，那么这样可以省掉一些繁琐的判断。建议在线程启动、文件流打开的时候要严格限制只允许调用一次，而停止或者关闭的操作允许多次调用，因为一般停止和关闭这类操作都不止一处需要调用，至少有正常关闭和程序执行过程中遇到异常关闭两种，所以在关闭的时候不要限制那么严格也是有好处的。

非运行时异常

人们对非运行时异常褒贬不一，大家争论的地方主要在于非运行时异常必须得处理，而且它让代码变得很难看。一行代码变成了四行之外，还多了一层缩进。结果就是哪里出现非运行时异常，哪里的代码就会丑爆了。那么何时该使用非运行时异常，一般来说，非运行时异常都是可以恢复的。

非运行时异常的优点

强制程序员去处理出错的情况。如果不强制大家去处理这个情况，很多人都会选择不处理异常，比如下面的方法：

file.delete();

这个方法是有一个返回值的，返回true表示删除成功，false表示删除失败，这里，没有抛出非运行时异常，所以很多人都会闭上眼睛假装不会失败，导致程序不稳定。

非运行时异常的缺点

• 那些发生概率极低或者明知道不会发生问题的地方，也必须要捕获异常。
  比如下面的代码：

try {
    Thread.sleep(1000);
} catch (InterruptedException e) {
    e.printStackTrace();
}

这段代码丑陋的地方在于，这个线程，我根本不打算去执行interrupt方法，sleep方法就根本不会抛出异常，catch代码段根本不可能执行到，或者即便抛异常了，也没什么大不了的，但是我们还是得去捕获这个异常。Google也发现了这个问题，所以给了大家另外一个选择：

SystemClock.sleep(1000);

• 一些设计的不好的异常，即便捕获了，也无法处理。

try {
    JSONObject jsonObject = new JSONObject("");
} catch (JSONException e) {
    throw new RuntimeException(e);
}

比如这里的JSONException，虽然它是非运行时异常，但是几乎不可恢复，所以在catch代码块中也就只能再抛出一个运行时异常。

总结

实际工作中遇到的情况各种各样，但是一个总的原则就是通过分析错误的产生原因和严重程度来选择处理错误的方式。