Rappelons la définition des arbres binaires à l'aide d'un type abstrait :
interface ArbreBinaire { boolean estVide(); } class AVide implements ArbreBinaire { public boolean estVide() { return true; } } class ACons implements ArbreBinaire { int étiquette; ArbreBinaire gauche, droit; ACons(int étiquette, ArbreBinaire gauche, ArbreBinaire droit) { this.étiquette = étiquette; this.gauche = gauche; this.droit = droit; } public boolean estVide() { return false; } }
Alors que les constructeurs ne sont définis que dans les classe concrètes AVide et ACons, il est tentant de déclarer des destructeurs étiquette, gauche et droit dans l'interface ArbreBinaire :
interface ArbreBinaire { // ... int étiquette(); ArbreBinaire gauche(); ArbreBinaire droit(); }
La définition de ces méthodes dans la classe ACons est immédiate :
class ACons implements ArbreBinaire { // ... public int étiquette() { return étiquette; } public ArbreBinaire gauche() { return gauche; } public ArbreBinaire droit() { return droit; } }
Par contre, leur définition dans la classe AVide est problématique ; l'idéal serait de ne pas les définir, mais dans ce cas AVide ne serait plus une réalisation de ArbreBinaire. Il faut donc les définir, mais au lieu de retourner une valeur, ces méthodes vont déclencher une exception, à l'aide de l'instruction throw :
class AVide implements ArbreBinaire { // ... public int étiquette() { throw new UnsupportedOperationException(); } public ArbreBinaire gauche() { throw new UnsupportedOperationException(); } public ArbreBinaire droit() { throw new UnsupportedOperationException(); } }
Cette solution peut s'appliquer à toute méthode, déclarée dans l'interface, mais qui n'est pas définie dans une classe. Dans le cas d'une méthode partielle, c'est-à-dire qui n'est pas définie pour certaines valeurs de ses arguments, on pourra déclencher plutôt l'exception java.util.NoSuchElementException. Ainsi, dépiler une pile vide devrait déclencher cette exception.