SFML et exceptions

[kamui]

Salut,

J'aimerais savoir pourquoi SFML ne lance pas d'exceptions donc je vais directement m'adresser au créateur :

(attention, je ne suis pas contre, je trouve que c'est une bonne idée, c'est pourquoi je veux m'assurer d'avoir compris le pourquoi du comment)

Pourquoi ce choix Laurent ? En plus de la raison que je soupçonne que des blocs try/catch et toutes les classes supplémentaire que ça oblige à coder, ça rend le code plutôt désagréable, y'a-t-il une raison technique ? Parce qu'en terme de performance, les gestion des exception a tendance à être mieux que les gestion "OK/KO".

Ou encore, est-ce un choix conceptuel du genre "je laisse la responsabilité à l'utilisateur de gérer les différents cas d'erreur, et je leur colle juste un petit warning sur l'erreur standard pour qu'il soit averti que ça risque de pêter" ? Ton objectif était-il de permettre aux programmes de continuer de tourner même avec des erreurs qui dans l'absolu n'ont pas de raison d'être bloquantes (par exemple un draw d'un sprite avec une texture vide est tout simplement ignorée ou des choses comme cela ?) ?

[Laurent]

Ton objectif était-il de permettre aux programmes de continuer de tourner même avec des erreurs qui dans l'absolu n'ont pas de raison d'être bloquantes

A la base il me semble que c'était principalement pour cette raison. Rien n'était censé être fatal, on pouvait avoir un programme qui tourne (dans le sens "qui ne crash pas") quoiqu'il arrive.

C'était aussi un choix pratique : ça me facilite grandement la tâche pour les bindings.

Maintenant, plus SFML évolue et plus je me rend compte que la gestion des erreurs est très insatisfaisante. Du coup je risque de passer un coup de bulldozer dessus dans SFML 3.

[kamui]

...et en venir aux exceptions ?

[christophedlr]

Je pense que ça a atteint un point où Laurent ne va pas avoir le choix.

[Laurent]

...et en venir aux exceptions ?

Pourquoi pas. Le sujet est complètement ouvert.

Je pense que ça a atteint un point où Laurent ne va pas avoir le choix.

Pourquoi dis-tu ça ? Quelle est ton opinion sur le sujet ?

[kamui]

Encore une fois je penses que c'est une question de choix de conception : en terme de rigueur, robustesse, et/ou performances, cela reste de toute façon la meilleure approche (pour le gain de performance, je ne saurais l'expliquer, j'ai simplement lu un article qui allait dans ce sens).

Si la priorité est d'avoir un code léger et clair (ce que négligent un peu et très souvent (un peu trop et trop souvent à mon gout) les développeurs qui ont de fortes connaissances), qui laisse un peu plus de responsabilités à l'utilisateur (volontairement j'entends), il y a des méthodes pour.

Moi ce qui m'intéresse surtout, c'est qu'entends-tu par  "plus je me rend compte que la gestion des erreurs est très insatisfaisante" ?

Parce que je suis sur qu'il y a moyen d'avoir un système de gestion des cas d'erreurs, concis et clair, bien structuré et qui ne fait pas appel à des exceptions standards ou perso, donc ce serait super intéressant de savoir dans ce cas à quelles problématiques cela t'a conduit, vu que c'est cette dernière approche que tu avais choisi (peut-être pas assez franchement ?)

[Laurent]

Je ne pourrais pas te resortir tout ce qui avait été dit concernant la gestion d'erreur actuelle, et je n'ai pas le temps de me replonger dedans. Mais tu peux essayer de trouver la discussion correspondante sur le forum anglais -- ça avait déjà été discuté en profondeur.