Ca dépend ce qu'on fait, perso je catche assez souvent lorsque les erreurs sont récupérables et ça reste assez fréquent... Faut dire que je programme pas mal dans le serveur et que

cout << "fuck you";
exit(1);

Ou un assert dont l'effet est à peu de chose près le même n'est pas souvent une solution acceptable.

Dans un contexte où le soft ne doit pas crasher, là tu dois récupérer les erreurs. Mais sinon, c'est bien plus simple de faire un « assert(...); ».

Dans tous les cas, le cout + exit c'est une abomination. Va déboguer ton programme après.

Ou meme quand tu ecris une lib c'est assez peu acceptable. Note que l'on remplace facilement assert par un lancement d'exception en jouant sur la precompilation.

Chris_27
Posté le 19 mai 2012 à 13:55:07
Dans un contexte où le soft ne doit pas crasher, là tu dois récupérer les erreurs. Mais sinon, c'est bien plus simple de faire un « assert(...); ».

d) Tu imagines pas le nombre de fois que je vois ce genre de trucs, ces if not X exit.
Souvent si tu codes dans une optique réutilisable ou modulaire, tu ne peux pas décider de la fin du programme, tu dois juste nettoyer derrière toi et signaler plus ou moins précisément l'erreur. Ensuite c'est le code appelant (ton interface graphique, ton serveur etc...) qui peut décider quoi faire dans le contexte.

Beaucoup de programmeurs, même dans le monde pro, utilisent les exceptions comme des pieds, ou alors ils ne les comprennent pas. C'est pourtant un moyen très élégant de centralisé la gestion d'erreur.

l'utilite des exceptions et de gerer les erreurs proprement dependent beaucoup de ce que l'on ecris.

Perso, le code que j'ecris a pour but de resoudre un probleme extremement precis (calcul les plus petites valeures propre de cette matrice). Le code est court (<<10Kloc) et va tourner longtemps (>>1 CPU-jour). Toute erreur a l'execution veut dire que je n'aurais pas de resultat. Donc exit a du sens

Mais pour une lib ou pour un module qui vient s'imbriquer dans une application plus grande, toute forme de exit est catastrophique...

godrik: bof, moi ça ne me pose pas de soucis les assert(...) dans les libs. Si quelqu'un utilise la lib n'importe comment, qu'il se mange un « assert(false); » en plein figure.

Et je maintiens que je préfère ça à un assert(...); à simple exit(...); : c'est nettement plus facile à traiter au sein de gdb.

Chris, c'est pas completement clair.
Si tu as une lib de partitionnement par exemple (un truc que je fais souvent). Si un des algos amene a un assert(false), tu peux toujours utiliser un fall back plus simple. (A condition que la lib soit stateless.)

Perso, le code que j'ecris a pour but de resoudre un probleme extremement precis (calcul les plus petites valeures propre de cette matrice). Le code est court (<<10Kloc) et va tourner longtemps (>>1 CPU-jour). Toute erreur a l'execution veut dire que je n'aurais pas de resultat. Donc exit a du sens

Pour moi, c'est un peu comme si tu écrivais une routine d'importation de donnée pour ton usage perso. En ce sens tu vas pas faire de la super gestion d'erreur. A la fin de l'exécution du programme ça a marché ou pas avec éventuellement un message d'erreur, c'est tout ce qui intéresse.

Et la façon la plus facile de transmettre des erreurs avec des explications à une couche supérieure, ça reste quand même les exceptions.

Je veux tout à fait admettre que c'est largement acceptable pour certains cas, mais quand les architectures deviennent plus complexes, avec des sources de données, des IO, des contraintes de disponibilité, ça devient vite insuffisant.

Perso pour tout projet sérieux, j'accepterai jamais qu'une fonction de mon programme non rattachée au fil conducteur principal affiche des trucs en console ou décide de la fin du processus.
Pour moi, le rôle d'une d'une couche de service ou d'une lib, c'est de fournir une API de haut-niveau à disposition d'une interface GTK/console/web ou dieu sait quoi et c'est cette interface qui décide de comment elle réagit en cas d'erreur, si elle quitte silencieusement, si elle log puis elle envoie un http 500 ou autre.

Aie j'ai buggé!
Le 2e paragraphe de mon post vient tout à la fin.

http://littlebits.cc/about

Sympathique.

Programmeurs, enjoy https://www.jeuxvideo.com/forums/1-47-64864-1-0-1-0-serveur-teamspeak3-prog-infographie-et.htm Sa ne vous prendra que 30 seoncdes à lire ^^

• CryPumpkin Voir le profil de CryPumpkin

* Posté le 23 mai 2012 à 17:41:53 Avertir un administrateur
* Programmeurs, enjoy https://www.jeuxvideo.com/forums/1-47-64864-1-0-1-0-serveur-teamspeak3-prog-infographie-et.htm Sa ne vous prendra que 30 seoncdes à lire ^^

non mais ton topic n'avait même pas disparu en seconde page, inutile d'en faire de la pub envahissante comme ça.

* Paulop Voir le profil de Paulop
* Posté le 23 mai 2012 à 14:38:46 Avertir un administrateur
* http://littlebits.cc/about

Sympathique.

c'est vrai, on dirait des jouets pour enfants.

J'ai un soucis, j'utilise lua dans un projet, et quand je fais print ( 0xFFFFFFFF ) il me renvoie 4294967296 au lieu de 4294967295.
Pire c'est qu'il me sort la même valeur si je lui demande de m'afficher 0xFFFFFFF0 par exemple.

Il m'affiche la bonne valeur jusqu'à 0x00FFFFFF je dirais.

Le pire étant que quand j'utilise l'invité de commande lua et que je fais print, il m'affiche la bonne valeur, c'est juste dans mon code que cela fait ça.

Demain j'essaye de changer de compilateur, sait-on jamais, mais vous auriez pas une idée ?

(le lua.exe que j'ai a été compilé avec MinGW et je compile avec Visual C++)

j'ai déja eu le problème, LUA c'est virgule flottante double précision only.

"hurr durr mais la précision n'est pas un problème"

langage à jeter.

C'est pas logique vu que l’interpréteur fournit par le site affiche la bonne valeur et que je n'ai pas touché la config

Je pense avoir trouvé, je testerais ça ce soir j'ai pas le code sous la main.

Mais en fait il semblerait que Direct3D9 (et juste le 9) change le FPU state de double (ABI Windows utilise double et pas extended) à float.

Il faut utiliser D3DCREATE_FPU_PRESERVE pour empêcher ça.

1. Paulop Voir le profil de Paulop
2. Posté le 25 mai 2012 à 10:13:08 Avertir un administrateur
3. C'est pas logique vu que l’interpréteur fournit par le site affiche la bonne valeur et que je n'ai pas touché la config

ils ont dû le recompiler pour que lua utilise aussi des nombres entiers, c'est quelque chose qu'on voit quelquefois.

Non j'ai vérifié ^^
Je vais tester avec la constante dont j'ai parlé plus haut.

C'était bien la faute de D3D9

Petite anecdote, au début ça ne marchait pas mieux, j'ai cru que j'allais abandonner avant de voir que je compilais la dll du moteur graphique en release et que je testais le code qui embarque lua en debug. ^^