mental.dIseASe
Lieutenant
- Registriert
- Dez. 2008
- Beiträge
- 672
Guten Abend,
ich sitze seit vier Stunden an einem merkwürdigen Problem, das mir übelst den Kopf zermartert. Irgendwann im Verlauf des letzten ~3/4 Jahr ist in unserer Software ein catch-Block unreachable geworden. Ein Kollege hat den Code dann offenbar entfernt, weil der Compiler sonst wohl gemeckert hätte. Das Problem ist, dass der Code eigentlich sinnvoll war. Ich kann aber beim besten Willen in der git-History nicht erkennen, welche Änderung im Code selbst oder in Dependencies dieses compilerseitig gebotene Entfernen verursacht haben könnte.
Etwas Code:
Manager:
Außerdem haben wir eine von Exception abgeleitete Klasse:
Diese Exceptions werden von einem Aspekt generiert, der sämtliche Manager-Methoden umgarnt, um Exceptions aus der Datenhaltungsschicht hübsch zu verpacken.
Die Komponente, die den Manager verwurstet, sieht neuerdings so aus:
Vor diesem 3/4 Jahr war aber folgendes möglich:
Das wirft der Compiler mir jetzt aber vor die Füße. Angesichts von http://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.21 frage ich mich zwar, wie das vorher funktionieren konnte. Wenn ich aber den alten Stand mit diesem Code auschecke, baut es ohne Probleme.
An der Implementierung des EntityManagers hat sich in meinen Augen nichts geändert, das ich als dafür verantwortlich einstufen würde. Weder die Methode im Interface noch in der Implementierung hat irgendwie ihre Signatur geändert. Die Implementierung wird aber inzwischen nicht mehr per XML als Bean exponiert, sondern per ComponentScan. Auch einige Dependencies der Implementierung werden jetzt geautowired. Aus:
wurde also:
Aber das sollte doch komplett irrelevant sein.
Jetzt habe ich in der ConsumingClass also nur noch den Fallback-Block, der die vom Aspekt geworfene Exception fängt und nur sehr rudimentär behandelt. Das ist doof.
Was in der Zwischenzeit passiert ist:
- Implementierung kommt jetzt anders in den Spring-Container
Was nicht passiert ist
- die Signatur der Methode im Interface und in der Implementierung wurden nicht angefasst
- der Aspekt wurde nicht angefasst
- Die Paketstruktur ist gleich geblieben
- Die ConsumingClass hat sich, bis auf den weggefallenen catch-Block, nicht geändert
- Das Java-Target in der pom ist nachwievor 1.8
Ich werde zwar am Montag meine Kollegen dazu fragen, aber es wurmt mich, dass ich das heute nicht selbst lösen konnte. Irgendetwas übersehe ich. Hat irgendwer einen Einfall, was das sein könnte? Brauche ich Bier, um das sehen zu können?
ich sitze seit vier Stunden an einem merkwürdigen Problem, das mir übelst den Kopf zermartert. Irgendwann im Verlauf des letzten ~3/4 Jahr ist in unserer Software ein catch-Block unreachable geworden. Ein Kollege hat den Code dann offenbar entfernt, weil der Compiler sonst wohl gemeckert hätte. Das Problem ist, dass der Code eigentlich sinnvoll war. Ich kann aber beim besten Willen in der git-History nicht erkennen, welche Änderung im Code selbst oder in Dependencies dieses compilerseitig gebotene Entfernen verursacht haben könnte.
Etwas Code:
Manager:
Code:
public interface EntityManager {
public void save(Entity anEntity);
}Außerdem haben wir eine von Exception abgeleitete Klasse:
Code:
public class AspectException extends Exception {}Diese Exceptions werden von einem Aspekt generiert, der sämtliche Manager-Methoden umgarnt, um Exceptions aus der Datenhaltungsschicht hübsch zu verpacken.
Die Komponente, die den Manager verwurstet, sieht neuerdings so aus:
Code:
@Component
public class ConsumingClass {
@Autowired private EntityManager entityManager;
private void useTheManager(final Entity someEntity) {
try {
entityManager.save(someEntity);
} catch (final Exception exception) {
// some fallback exception handling
}
}
}Vor diesem 3/4 Jahr war aber folgendes möglich:
Code:
@Component
public class ConsumingClass {
@Autowired private EntityManager entityManager;
private void useTheManager(final Entity someEntity) {
try {
entityManager.save(someEntity);
} catch (final AspectException aspectException) {
// some elaborate exception handling
} catch (final Exception exception) {
// some fallback exception handling
}
}
}Das wirft der Compiler mir jetzt aber vor die Füße. Angesichts von http://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.21 frage ich mich zwar, wie das vorher funktionieren konnte. Wenn ich aber den alten Stand mit diesem Code auschecke, baut es ohne Probleme.
An der Implementierung des EntityManagers hat sich in meinen Augen nichts geändert, das ich als dafür verantwortlich einstufen würde. Weder die Methode im Interface noch in der Implementierung hat irgendwie ihre Signatur geändert. Die Implementierung wird aber inzwischen nicht mehr per XML als Bean exponiert, sondern per ComponentScan. Auch einige Dependencies der Implementierung werden jetzt geautowired. Aus:
Code:
public class EntityManagerImpl implements EntityManager {
private Dependency dependency;
public void save(final Entity anEntity) {
// save it
}
}wurde also:
Code:
@Component
public class EntityManagerImpl implements EntityManager {
@Autowired private Dependency dependency;
public void save(final Entity anEntity) {
// save it
}
}Aber das sollte doch komplett irrelevant sein.
Jetzt habe ich in der ConsumingClass also nur noch den Fallback-Block, der die vom Aspekt geworfene Exception fängt und nur sehr rudimentär behandelt. Das ist doof.
Was in der Zwischenzeit passiert ist:
- Implementierung kommt jetzt anders in den Spring-Container
Was nicht passiert ist
- die Signatur der Methode im Interface und in der Implementierung wurden nicht angefasst
- der Aspekt wurde nicht angefasst
- Die Paketstruktur ist gleich geblieben
- Die ConsumingClass hat sich, bis auf den weggefallenen catch-Block, nicht geändert
- Das Java-Target in der pom ist nachwievor 1.8
Ich werde zwar am Montag meine Kollegen dazu fragen, aber es wurmt mich, dass ich das heute nicht selbst lösen konnte. Irgendetwas übersehe ich. Hat irgendwer einen Einfall, was das sein könnte? Brauche ich Bier, um das sehen zu können?
