} catch (KeyNotFoundException knfe) {
  throw new RuntimeException("KEY NOT FOUND");
}

Das Ergebnis ist das folgende in trapo_entw.log:

Mrz292006 11:09:06 ERROR TechnischesLog '14' for queue: 'weblogic.kernel.Default' lwow TPN ERROR 000 15000 KEY NOT FOUND

Man sieht also nicht, um was für einen Key es sich handelt.

Ausserdem ist "Key" ein so vager Begriff, dass ich zumindest nicht direkt an eine Java Key-Klasse als Quelle gedacht habe.

Diese wenig aussagekräftige Fehlermeldung hat mich heute extrem Nerven gekostet.

Was läuft hier falsch?
- Es wird eine sinnvolle Exception geschluckt und durch eine RuntimeException ersetzt. Das kann noch Sinn machen, wenn man mit einem Fehler-Fall im Exception Handling keinen Ärger haben will, z.B. in einem static{} Block.
- Die Original-Exception wird nicht angehängt. Dadurch geht die Information dieser Original-Exception für den Aufrufer und das Log verloren.
- Die neue Exception ist nicht aussagekräftig.

Viel schöner ist doch das hier:

} catch (KeyNotFoundException knfe) {
  throw new RuntimeException("KEY NOT FOUND, 
      message = " + knfe.getMessage(), knfe);
}

Das ergibt im Log folgenden Eintrag:

Mrz292006 14:48:34 ERROR TechnischesLog '14' for queue: 'weblogic.kernel.Default' lwow TPN ERROR 000 15000 KEY NOT FOUND, message = No Key with ID 54 available in Key type de.dbsystems.tpn.obv.VStatusKey and Locale de_DE.

Nun wird direkt in der Message die Message der geschluckten Exception weitergegeben, und die geschluckte Exception wird auch weitergegeben.

Die Moral: Beim Einpacken von Exceptions sollte man aufpassen, dass man nicht wichtige Informationen verschluckt, sonst sucht sich irgendjemand irgendwann nach diesen Informationen dumm und dämlich.

So, das musste grad mal raus. :-)

Exceptions sind ohnehin ein dummer Kack. So!