2015-07-15 9 views
7

Ich mag es, Exception Klassen zu erstellen, deren Namen die anwendungsspezifischen Probleme angeben, die bemerkt und ausgelöst werden.Wie Wiederholungen in benutzerdefinierten Java-Ausnahmeklassen vermieden werden können

Um sie zu definieren, wird normalerweise eine neue class definiert, deren Super-Klasse ein Typ Exception ist.

Aufgrund der mehrfachen gemeinsamen Konstrukteuren in der Exception Klasse Elternteil, in der Regel der Unterklasse etwas wie folgt aussieht:

package com.example.exception; 

/** 
* MyException is thrown when some application-level expectation is not met. 
*/ 
public class MyException extends Exception { 

    public MyException() { 
     super(); 
    } 

    public MyException(String message) { 
     super(message); 
    } 

    public MyException(Throwable cause) { 
     super(cause); 
    } 

    public MyException(String message, Throwable cause) { 
     super(message, cause); 
    } 

} 

aus der Perspektive der DRY bei dieser Suche, finde ich diese Vorgehensweise mühsam, besonders wenn Exception Hierarchien definiert sind.

Ich bin vertraut mit Tools wie Lombok, die mit der Verringerung der Wiederholung für gängige Java-Muster helfen; Gibt es Vorschläge für Tools, die dieses spezifische Problem der Wiederholung von Ausnahmeklassen lösen?

+2

Das sieht gut aus für mich. –

+0

@SotiriosDelimanolis Ich glaube, dass der Punkt, den das OP versucht zu machen ist, dass, wenn er 10 benutzerdefinierte Ausnahmeklassen hat, er diesen Code in all diesen Ausnahmeklassen wiederholen muss. – CKing

+2

@CKing Nein, ich verstehe. Das wäre in Ordnung für mich. –

Antwort

4

Wenn Sie "Business" -Ausnahmen erstellen, sollten Sie nicht einfach alle Konstruktoren von Exception kopieren. Erstellen Sie stattdessen Ausnahmen, die Ihre Geschäftsobjekte verwenden. Zum Beispiel schlug fehl, wenn eine Anforderung, die von Ihrem Business-Objekt modelliert Request Sie vielleicht einen RequestFailedException mit einem einzigen Konstruktor erstellen:

public RequestFailedException(Request request) { 
    super("Request to " + request.getUrl() + " failed."; 
} 

Sie könnten sogar einen Verweis auf das Request Objekt in einem Feld speichern und einen Getter vorzusehen, so dass die Methode, mit der die Ausnahme behandelt wird, möglicherweise mehr Informationen darüber erhält, was passiert ist.

+1

Ich stimme zu, dass für bestimmte "Ausnahmen" die Kapselung relevanter Informationen eine gute Idee ist, aber nicht alle "Ausnahmen" haben diese Anforderung; sind nicht die meisten Ausnahmen nur benutzerdefinierte Wrapper? Ich finde es einfach ärgerlich, dass für diese Art von "Exceptions" dieser doppelte Code erstellt wird. –

+1

Ich denke, wir (die Java-Entwickler) neigen dazu, Ausnahmen zu oft zu werfen. Versuchen Sie beispielsweise, Methoden zum Überprüfen einer Bedingung anzugeben, anstatt eine Methode zu implementieren, die eine Ausnahme auslöst, wenn die Bedingung nicht erfüllt ist. Wenn etwas schief geht, versuchen Sie, widerstandsfähig zu sein und etwas zurückzugeben, das vielleicht nicht perfekt ist, aber dennoch für den Anrufer nützlich ist. – hzpz

+1

Obwohl ich völlig einverstanden bin mit dem, was diese Antwort sagt, ist es nicht, was das OP gefragt hat. –

Verwandte Themen