Interfaces et implémentations avec checked exceptions

Version imprimable

Bonjour,

Un exemple vaut mieux qu'un grand discours :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 public interface MyInterface { public int do (); } class MyClass extends MyInterface { @Override public int do () { try { return ...; } catch (IOException e) { // Que faire avec la checked exception } } }
(Le fait que la classe soit package-private est important.)

Voilà donc, je ne sais pas quoi faire avec l'IOException. Pour moi, la seule solution (évidente) est de l'encapsuler dans une MyException (extends RuntimeException), mais rien ne dit dans l'interface publique que cette MyException peut être renvoyée. De plus, selon moi, une RuntimeException n'est lancée que lors d'une erreur de programmation (typiquement un manque de vérification préalable, voir NullPointerException, IllegalArgumentException, ClassCastException, ArithmeticException, etc.)

D'avance merci.

Il n'y a pas de bonne réponse : l'interface est mal fichue. Elle devrait au moins autoriser une exception quelconque.

La solution adoptée (que je crois la meilleure) d'utiliser une interface intermédiaire qui, elle, définit des RuntimeExceptions.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public interface MyInterface {
  public int doSomething ();
}
 
public class MyRuntimeException extends RuntimeException {
  // Tous les constructeurs
}
 
/**
 * MyInterface est pleine de bugs, celle-ci est meilleure parce qu'elle déclare MyRuntimeException.
 */
public interface MyOwnInterface extends MyInterface {
  @Override public int doSomething () throws MyRuntimeException;
}
 
class MyClass extends MyInterface {
  @Override public int doSomething () throws MyRuntimeException {
    try {
      return ...;
    } catch (IOException e) {
      throw new MyRuntimeException("Pas pu faire quelque chose", e);
    }
  }
}

30/04/2010, 16h10
adiGuba
Salut,

Un sujet délicat s'il en est, et sujet à de multiple controverse...

Citation:

Envoyé par dingoth

De plus, selon moi, une RuntimeException n'est lancée que lors d'une erreur de programmation

C'est souvent le cas en Java... mais pas forcément !

Une RuntimeException est avant tout une "unchecked-exception", c'est à dire une exception dont la gestion n'est pas vérifiée par le compilateur, à l'inverse des "checked-exceptions".

Il faut savoir que cette notion de "checked-exception" est assez spécifique à Java (je ne connais pas beaucoup d'autre langage gérant cela), et cela apporte beaucoup de débat...

Le problème des checked-exceptions vient justement du fait qu'elles sont contrôlées par le compilateur, et que cela peut s'avérer assez lourd.

Cela oblige à faire un code propre si l'exception doit à tout prix être traitée, mais à l'inverse cela entraine trop souvent des maladresse.

Pire dans le cas d'une interface, le simple fait de déclarer une checked-exception implique que l'on devra la traiter dans tous les cas, y compris si l'implémentation ne l'utilisera pas...

Les unchecked-exceptions (RuntimeException en Java) sont beaucoup plus souple, car on n'a pas à les traiter obligatoirement.

Bien souvent une absence de gestion peut s'avérer bien plus propre qu'une gestion forcée et archaïque...

Donc dans ton cas, je ferais remonter une RuntimeException quelconque dans mon implementation, en l'indiquant bien dans la documentation de ta classe.

Pour cela tu peux utiliser une exception spécifique ou tout simplement une exception englobante. UndeclaredThrowableException me semble tout indiqué :
Code:

1 2 3 } catch (IOException e) { throw new UndeclaredThrowableException(e); }
Le seul problème c'est que tu as un niveau d'encapsulation en trop.
Perso je pense qu'il serait intéressant de pouvoir remonter une checked-exception silencieusement, et donc de remettre en cause tout cela... mais c'est tout un débat ;)

a++

[edit] Tu as posté pendant que je saisissait mon message. Je ne pense pas que l'interface soit mal foutu. Le fait de déclarer une exception dans une interface peut alourdir son utilisation, en particulier si l'exception n'est pas remonté par toutes les implémentations...