blob: 1aa84b0a15c1bb423eb9dec7168654481211628c (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
// Copyright Yahoo. Licensed under the terms of the Apache 2.0 license. See LICENSE in the project root.
/* -*- c-basic-offset: 4 -*-
*
* $Id$
*
*/
package com.yahoo.io;
import java.util.logging.Logger;
import java.util.logging.Level;
/**
* What to do if a fatal condition happens in an IO component.
*
* <P>
* TODO: We need to re-think this design a bit. First off, we
* probably need to make the interface an abstract class
* or a pure interface type. Second we provide a few
* default implementations which are named after what policy
* they implement -- like SystemExitOnError etc. Also,
* runnables that have fatal error handling capability should
* probably implement a standard interface for get/set etc.
* Also, we should encourage application authors to provide
* their own, application specific error handlers rather than
* relying on the default.
*
* @author Steinar Knutsen
*/
public class FatalErrorHandler {
protected static final Logger log = Logger.getLogger(FatalErrorHandler.class.getName());
/**
* Do something reasonable when a an Error occurs.
*
* Override this to change behavior. Default behavior is to log
* the error, then exit.
*
* @param t The Throwable causing the handler to be activated.
* @param context The object calling the handler.
*/
public void handle(Throwable t, Object context) {
try {
log.log(Level.SEVERE, "Exiting due to error", t);
} finally {
Runtime.getRuntime().halt(1);
}
}
}
|
