Tirar (y atrapar) Throwable (o Exception) es generalmente una mala práctica porque 'cubre' cualquier excepción específica que pueda querer atrapar. A continuación, tendría que recurrir a la fealdad, como a continuación:
public void myMethod() throws Throwable {
if (x) {
throw new MyException1();
}
if (y) {
throw new MyException2();
}
}
public void callingMethod() {
try {
myMethod();
}
catch(Throwable t) {
if (t instanceof MyException1) {
// handle exception 1
}
else if (t instanceof MyException2) {
// handle exception 2
}
else {
// handle other exceptions
}
}
}
Cuál es propenso a errores (y lo ha marcado la CheckStyle como una violación del código). Es mucho más preferible tener un código como éste:
public void myMethod() throws MyException1, MyException2 {
if (x) {
throw new MyException1();
}
if (y) {
throw new MyException2();
}
}
public void callingMethod() {
try {
myMethod();
}
catch(MyException1 e) {
// handle exception 1
}
catch(MyException2 e) {
// handle exception 2
}
}
Manejo de una excepción con sólo llamar printStackTrace() por lo general no es una buena idea. printStackTrace() envía el stacktrace al error estándar, que puede no leerse en absoluto. Una mejor opción es usar el recurso de registro de la aplicación (como log4j) para informar la excepción. Incluso entonces, simplemente iniciar sesión podría no ser suficiente.
Mi regla de oro es:
Si usted puede manejar una excepción a nivel local, que lo hagan. Por ejemplo, cuando analizar una cadena como un entero se puede coger el NumberFormatException y devolver un valor por defecto:
prvate int parseAmount(String amountValue) {
int amount;
try {
amount = Integer.parseInt(amountValue);
}
catch(NumberFormatException e) {
// default amount
amount = 0;
}
return amount;
}
Si usted no puede manejar una excepción a nivel local, considere si debe exponer el tipo de excepción que está siendo lanzada.Si este tipo es algún tipo (dependiente de la implementación) oscura, a continuación, envolviéndolo en su propio tipo de excepción genérica es probablemente una buena idea:
private Customer getCustomer(int customerId) throws ServiceException {
try {
return customerService.getCustomer(customerId);
}
catch(CustomerServiceSpaghettiTangledException e) {
throw new ServiceException("Error calling the customer service", e);
}
}
Aquí 'ServiceException' es una subclase de excepción creada por ti. Spring también ofrece un exception hierarchy específicamente para este propósito.
Al incluir la excepción, oculta los detalles de implementación, haciendo que su capa de servicio sea mucho más simple de usar.
Si decide lanzar una excepción de su método, tendrá que manejarlo 'más arriba' en la pila de llamadas. Esta puede ser una página de error genérico en su aplicación web que indica que algo salió mal y posiblemente proporciona un mensaje de error o código. En algunos casos, el código de nivel superior puede intentar un reintento o posiblemente una forma alternativa de obtener el resultado requerido.
probablemente esto le dará una explicación: http://stackoverflow.com/questions/498217/when-should-throwable-be-used-instead-of-new-exception – Serge
"throws Throwable" es más comúnmente utilizado en SDKs y definiciones de framework. Aquí hay un ejemplo en el marco de prueba de Android donde lo usan: http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.4.2_r1/android/test/ InstrumentationTestCase.java # InstrumentationTestCase –