Discussion :

[sboffin]

Salut a tous,

J'arrive de java et de ces exeption et je me demande si en dotnet il y a l'equivalent du throws (et non du throw) en dotnet.

En java si nous declaron une methode
Public sub test() throws exception
....
end sub

cela va indiquer a la personne qui utilise la method test de la metre dans un try catch.

Si cela n'esite pas en dotnet comment faire pour savoir les exeptions lancer par une methode ?

[Invité]

Pour interecepter une exception il faut utilisé le try catch, et pour généré une exception il faut utilisé le throw autrement je ne vois rien d'autre ormis l'heritage pour créer classe permettant la gestion d'exception

[dev01]

Salut .

il n'existe aucun équivalent au throws de java en dotnet. Pour savoir quelles sont les execptions levées par une méthode, il faut lire la doc ...

En dotnet rien ne t'oblige à gérer une execption, ces dernieres étant automatiquement remonté suivant la pile d'appel pour finalement, si elle n'est pas intercepté, etre traité par le moteur dotnet.

Je ne m'engage volontairement pas dans le débat "c'est en mieux en java, non c'est mieux en dotnet", les deux systèmes ayant leurs avantages et leurs inconvénients.

[sboffin]

Bon la tu piques ma curiosite ....

Comment ca peut etre bon comme ca en dotnet. ????????

Moi quand je lance une exeption dans 100% des cas c'est pcq je veux que la personne faisse qqc avec et non se mette a lire une doc qui n'est probablement pas encore la ... ou laisse le code aller et un jour se rendre compte que l'exeption existe .....


Lancer des exception dans les nuages n'est pas tres productif.

Dans mon cas j'ai un DLL qui lance FormatException et j'ai du mal a me convaincre de mettre en prod ce DLL en utilisant le throw FormatException .

Je suis en reflexion pour changer mon code et retourner 8 etages plus haut un code qui va indiquer clairement a l'utilisateur de mon DLL qu'il a un invalidFormat.

[Thomas Lebrun]

C'est aussi à cela que serve les tests.

Tu dois bien testé ton application pour t'assurer que tu as bien catcher toutes les exceptions que tu as lancées.

[dev01]

Moi quand je lance une exeption dans 100% des cas c'est pcq je veux que la personne faisse qqc avec et non se mette a lire une doc qui n'est probablement pas encore la ... ou laisse le code aller et un jour se rendre compte que l'exeption existe .....

Si tu lances ton execption dans 100% des cas alors tu n'as pas compris à quoi servent les execptions ...

D'autre part ce que je dit que le programmeur qui utilise ta librairie doit avoir une doc clair (evidement tu documentes ton code hein ?) et que s'il souhaite gérer l'exception que ta fonction peut lever, ben il sait quelle est exactement l'exception à gérer. De plus comme le dit Morpheus, les tests servent à vérifier que toute les cas possibles sont evisagés.

Lancer des exception dans les nuages n'est pas tres productif.

C'est ton point de vu et de plus n'as pas compris ce que je voulais dire. J'ai simplement dit que si je ne veux pas traiter ton execption dans la méthode qui appel la tienne parce que je préfére le faire dans la méthode supérieure, ben je peux simplement.

Dans mon cas j'ai un DLL qui lance FormatException et j'ai du mal a me convaincre de mettre en prod ce DLL en utilisant le throw FormatException .

Je suis en reflexion pour changer mon code et retourner 8 etages plus haut un code qui va indiquer clairement a l'utilisateur de mon DLL qu'il a un invalidFormat.

Ben moi j'ai du mal à te comprendre la ...

Pour finir un petit exemple de pourquoi j'aime pas la version Java de cela .

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 void ClickHandler(ActionEvent e)
{
    try
    {
        uneMethode();
    }
    catch(FormatException f)
    {
        //// ;
    }
}
 
public void uneMethode() : throws FormatExecption
{
    try
    {
        taMethode();
    }
    catch(FormatException f)
    {
        throw f;
    }
}

Tu es bien d'accord que le try catch ne sert à rien dans la fonction uneMethode mais est imposé par Java ? De plus si je ne veux pas traiter l'execption dans uneMethode c'est parce que je souhaite appeller une fonction qui n'est pas la classe de uneMethode mais dans celle de l'interface graphique.

en dotnet (ici C#)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
public void ClickHandler(object sender, EventArgs e)
{
    try
    {
        uneMethode();
    }
    catch(FormatException f)
    {
        //// ;
    }
}
 
public void UneMethode() 
{
   TaMethode();
}

c'est plus simple. De plus si jamais j'ai 4 niveau d'appel à remonter alors y a aucun pb.
Effectivement je suis d'accord pour dire que la méthode dotnet à un inconvénient qui est de ne pas savoir si ton execption va être intercepté et quelles sont les execptions qui sont levé par la fonction, mais une bonne documentation et c'est réglé. Quant au premier point, une execption étant autonome (normalement), tu n'en as rien à faire.

[Mose]

+1 pour dev01. Je préfère le système de .Net

Et quand je mets une DLL en prod, je fais un try/catch SYSTEMATIQUEMENT sur toute méthode de la couche Interface, comme ça l'utilisateur final ne voit jamais de gros crash, mais au pire, un message "l'application a rencontré des problèmes, merci de contacter votre administrateur". Et bien evidemment je fais un pti log de l'erreur avec toutes ses InnerExceptions

[sboffin]

Premierement oui je sais a quoi servent les exceptions j'ai quand meme 7 ans d'experiance en java .....

Ok le 100% c'etait un abus.

Et oui quand tu lances une exception elle doit avoir un but.
Il ya des exceptions qui doivent etre visibles aux utilisateurs. Et cela n'a rien a voir avec le fait de tester ou pas ton code.

Quand je lance un formatException c'est pcq j'estime que dans mon dll formatException n'est pas qqc qui doit faire planter/crash le programme. J'estime que formatException est une exception que l'utilisateur de mon dll doit reagir dessus.

Dans reagir je veux dire il doit etre mis au courrant qu'une exception et la mais la luis de faire ce qu'il desire (mais il est informe de son existance).

Mose je suis d'accord avec le fais de logger les exceptions non "catcher".
Mais dans mon cas l'exception est la pour forcer le programmeur a reagir dessus.

Si le progrmmeur a une formatException il peut mettre du code en place pour corriger cette erreur et faire un nouvel appel a la method qui a lance cette exception.

Le but de cette exception n'est pas d'aboutir dans le log mais de mettre du code en place pour corriger le probleme.

Et oui si il y a une bonne doc et tout et tout le programmeur vas voir cette exception ... mais il n'est pas obliger de faire qqc avec.

Petite clarification ....
Quand je parle d'utilisateurs je parle des utilisateur du dll donc des programmeurs.

[Mose]

Mouaip...
* Bah si tu veux un langage permissif, où le programmeur est responsable des exceptions qui remontent, tu fais du .Net

* Si tu veux un langage non permissif, où le programmeur est forcé de bien faire les choses sous peine de non-compilation, tu fais du Java.

Après les jugements de valeurs dépendent de l'expérience chaque individu et de ses méthodologies de travail.

Personnellement, je préfère qu'une exception remonte tous les étages, pour pouvoir avoir un lien direct et rapide sur la cause première de l'erreur (tout au fond de la pile d'exécution). Avec le débuggeur de VS, je trouve l'origine du pb très vite.
De même, si je n'ai que peu de temps pour coder, et que je fais du "quick'n dirty" je ne passe pas 10 ans à implémenter les 10 étages de 'catch/throw'.

Autre langage, autres moeurs

[dev01]

Mose je suis d'accord avec le fais de logger les exceptions non "catcher".
Mais dans mon cas l'exception est la pour forcer le programmeur a reagir dessus.

le problème reste donc entier avec Java.

Si tu as un developpeur qui se contente de mettre un throws sur sa méthode ou est l'obligation de réaction ?

Enfin pour clore le sujet : Il n'y a pas d'équivalent au throws de Java, que cela soit dommage ou non tient au débat philosophique.

[Mose]

Il n'y a pas d'équivalent au throws de Java, que cela soit dommage ou non tient au débat philosophique.

Blague de consultant en développement : "C'est pas un bug, c'est une feature"