Custom Exception

[wSam]

Hallo zusammen

Ich habe eine eignen Exception gebastelt:

public class EncryptionServiceException extends Exception {
  
  /**
   * The constant <code>serialVersionUID</code>
   */
  private static final long serialVersionUID = 4391083938613576892L;
  /**
   * The constant <code>CONFIGURATION_ERROR</code> is for errors which occurres from the 
   * configuration.
   */
  public static final String CONFIGURATION_ERROR = "configuration error";
  /**
   * The constant <code>TYPE_NOT_SUPPORTED_ERROR</code> is for errors which occurres when 
   * a property type will be used which is not supported.
   */
  public static final String TYPE_NOT_SUPPORTED_ERROR = "Type not supported error";

  private String m_exceptionType;

  /**
   * Constructor for EncryptionServiceException
   * @param exceptionType The exception type: 
   * @param cause
   */
  public EncryptionServiceException(String exceptionType, Throwable cause) {
    super(cause);
    m_exceptionType = exceptionType;
  }

  /**
   * Constructor for EncryptionServiceException
   * @param exceptionType
   * @param message
   */
  public EncryptionServiceException(String exceptionType, String message) {
    super(message);
    m_exceptionType = exceptionType;
  }

  /* (non-Javadoc)
   * @see java.lang.Throwable#toString()
   */
  public String toString() {
    return "EncryptionServiceException: " + m_exceptionType + " occurred";
  }

Macht der Konstruktor aufbau Sinn mit dem Aufruf des Super Konstruktors zuerst?

Danke und Gruss

 

[limago]

Der Code ist etwas redundant.

public class EncryptionServiceException extends Exception {

	private String exceptionType;

	public EncryptionServiceException(String exceptionType) {
		
		this(exceptionType, null ,null);
	}

	public EncryptionServiceException(String exceptionType, String message, Throwable cause) {
		super(message, cause);
		this.exceptionType = exceptionType;
	}

	public EncryptionServiceException(String exceptionType,String message) {
		this(exceptionType, message ,null);
	}

	public EncryptionServiceException(String exceptionType,Throwable cause) {
		this(exceptionType, null ,cause);
	}

}

Was ist mit der Message. Must Du nicht getMessage überschreiben, bzw. eine Message an die Superklasse mitgeben?

 

[wSam]

Hmm keine Ahnung, sollte ich?

 

[limago]

Glaub schon! Wenn Deine Exception in einem Stacktrace ausgegeben wird, wird intern getMessage verwendet.

try {
// Deine Logik
} catch( Exception e) { // ACHTUNG NICHT EncryptionServiceException

e.printStackTrace();
// bzw
System.out.println(e.getMessage());
}

liefern dann ein richtiges Ergebnis. Der Sinn von ExceptionType ist mir auch nicht so ganz klar. Warum baust Du das nicht gleich in die Message ein. Schreib doch mal was zum Hintergrund.

 

[wSam]

Also ich wollte die Exceptions in die zwei Typen CONFIGURATION_ERROR und TYPE_NOT_SUPPORTED_ERROR unterteilen, damit ich aus der Fehlermeldung direkt sehen kann, um was für einen Typ es sich handelt.

Wie würdest du das machen?

 

[limago]

2 Möglichkeiten

Erstens Du bohrst Deine Konstanten auf.
"EncryptionServiceException: configuration error occurred";
bzw.

"EncryptionServiceException: Type not supported error occurred";
und übergibst Sie bei der Konstruktion als Message.

oder zweitens

Du leitest zwei weitere Exceptionklassen ab, dann kannst Du die Fehler nicht nur an der Meldung, sondern auch am Typ unterscheiden. Das ermöglicht Dir dies.

try{
 //Deine Logik
} catch( UnsupportedEncryptionServiceException e) {
 // handle dies ..
}
catch( ConfigurationEncryptionServiceException e) {
 // handle jenes..
}

aber auch

try{
 //Deine Logik
} catch( Exception e) {
 // handle alles ..
}

ganz wie es Dir beliebt.

 

[schnuffie]

Nur mal so eine Meinung:

In unseren Systemen schreiben wir regelmäßig eigene Exceptions für die Fehler in der Fachlogik. Aussagekräftige Namen und eine sinnvolle Vererbungshierarchie sind das A und O dabei.

Beispielsweise würde ich immer eine zentrale Fachlogik-Exception erstellen, die alle nach außen sichtbaren Schnittstellen beinhalten. Weiterhin könnte man sich für eine Personlese- und -speicherklasse überlegen, z.B. eine PersonSchreibeException von einer PersonLeseException abzuleiten, was den Vorteil hätte, in der Throw-Klausel der schreib-Methode nur die PersonSchreibeException zu erwähnen und im eigentlichen Programmcode könnte man vorher lesen (also PersonLeseException möglich), ob die übergebenen Daten überhaupt schon vorhanden sind und somit geändert werden könnten.