Discussion :

[Flob90]

Je suis d'accord avec Klaim, dans l'idéal des comparaisons ca se fait sur des benchmark en situation réel, pas sur des morceaux de codes isolés qui ne sont en rien fidèles à la complexité en situation réel.

Par contre le fait qu'elles restent aussi performantes en situation simple montre quand même que l'implémentation de base d'un tel système n'est pas pénalisant en soit. Par contre il l'est peut-être pour les optimisations éventuelles que le compilateurs pourrait faire en situation réel.

Sinon, comme quasiment tout le monde dans les discussions, il ignore complètement le cas ou on desactive les exceptions et qu'on ne fais aucune verification d'erreur (on compte sur des tests massifs avant publication).

Je ne comprend pas ce que tu veux dire ici. Si on désactive le système de gestion d'exceptions/erreurs, alors la seul conséquence est que ca plantera en situation exceptionnel.

@Klaim: Lorsque tu avais testé, tu avais comparé les performances en situation normale ou en situation exceptionnelle ?

[Klaim]

e ne comprend pas ce que tu veux dire ici. Si on désactive le système de gestion d'exceptions/erreurs, alors la seul conséquence est que ca plantera en situation exceptionnel.

Si tu demandes au compilo de désactiver toute gestion d'exception ET tu n'utilises ni de throw ni de catch, c'est différent de si tu n'en utilises pas et que tu n'as pas déasactiver la gestion d'exception. Peut être pas dans les récentes versions des compilo, mais yavait une différence de perf il y a plusieurs années.

Sinon pour les comparaison, toujours dans le cas normal de l'utilisation de l'appli, dans monc cas un jeu qui dont on aurait réinjecté les inputs et qui est basé sur une boucle de mises a jour avec a fréquences d'affichage et de mise a jour fixes. Je considère même pas les cas extremes.

[loufoque]

Malheureusement, le seul moyen pour trouver quel est le mécanisme utilisé pour la gestion des exceptions est de compiler un petit programme les utilisant et d'analyser l'assembleur généré.

Le mécanisme utilisé est typiquement défini par l'ABI.

[therwald]

De base de donnée? Personellement pas spécifiquement, mais les contraintes du model, quel que soit l'implémentation, oui.

La différence c'est que selon le type de vérification et le type d'implémentation, le model peut ou pas être vérifié en amont de la base de donnée.


Je sais pas si ça réponds à ta question.

Oui, je ne citais la base de données qu'a titre d'exemple. Globalement, certaines règles de cohérence de modèle ne peuvent être vérifiées (facilement) par un SGBD, et dans d'autres cas le support du modèle dont on cherche à préserver la cohérence ne supporte pas nativement de vérification de cohérence. Dans ce cas il peut être nécessaire de vérifier la cohérence des données transmises en amont et de refuser les données incohérentes EN AMONT. Dans ce cas ai-je raison de conclure de ta réponse qu'on consid-re ça quand même comme des post-conditions (je cherche à affiner ou corriger ma compréhension du concept)? Pour ma part dans ce cas là je jette une exception, parce que:
1) c'est une situation exceptionnelle (les données normales, donc le cas général, vérifient les conditions)
2) le renvoi d'un code d'erreur s'il est non-traité peut entraîner une continuation du traitement alors qu'on est sorti du domaine de définition, avec d'éventuelles conséquences pas forcément maîtrisables sur des ressources potentiellement précieuses (le SGBD est mon exemple fétiche, mais un stockage fichier plus classique peut avoir le même prix sans compter d'autres conséquences potentiellement irrattrapables auxquelles je ne pense pas à l'instant T) ==> il FAUT arrêter tout de suite
3) un modèle d'exception bien conçu permet d'arrêter le traitement de manière fiable dès que le problème est détecté ET de donner des informations sur la raison et le contexte de l'arrêt

[Klaim]

Oui, je ne citais la base de données qu'a titre d'exemple. Globalement, certaines règles de cohérence de modèle ne peuvent être vérifiées (facilement) par un SGBD, et dans d'autres cas le support du modèle dont on cherche à préserver la cohérence ne supporte pas nativement de vérification de cohérence. Dans ce cas il peut être nécessaire de vérifier la cohérence des données transmises en amont et de refuser les données incohérentes EN AMONT. Dans ce cas ai-je raison de conclure de ta réponse qu'on consid-re ça quand même comme des post-conditions (je cherche à affiner ou corriger ma compréhension du concept)? Pour ma part dans ce cas là je jette une exception, parce que:
1) c'est une situation exceptionnelle (les données normales, donc le cas général, vérifient les conditions)
2) le renvoi d'un code d'erreur s'il est non-traité peut entraîner une continuation du traitement alors qu'on est sorti du domaine de définition, avec d'éventuelles conséquences pas forcément maîtrisables sur des ressources potentiellement précieuses (le SGBD est mon exemple fétiche, mais un stockage fichier plus classique peut avoir le même prix sans compter d'autres conséquences potentiellement irrattrapables auxquelles je ne pense pas à l'instant T) ==> il FAUT arrêter tout de suite
3) un modèle d'exception bien conçu permet d'arrêter le traitement de manière fiable dès que le problème est détecté ET de donner des informations sur la raison et le contexte de l'arrêt

En gros pour moi ça dépends d'ou viennent les infos. Si les infos sont exclusivement générées par l'application et un set d'applications qui sont censé marcher ensemble et communiquer de manière fermé (c'est a dire que la communication n'est pas possible 'avec d'autres applis, même si ces applis peuvent connaitre le protocole de communication), alors des assertions suffisent parceque si il y a un probleme avec la cohérence des données, ça viens forcément de l'appli elle même, et il faut le corriger.

Si les données peuvent venir de l'exterieur (plus courant) alors mieu vaut utiliser des exceptions OU BIEN, si on peut s'attendre a des erreurs et qu'on peut les gérer immédiatement, juste les gérere et avoir un systeme (qui peut être a part) pour enregistrer qu'il y a eu un probleme (log ou stack d'erreurs accessibles au runtime, ou autres solutions).

[therwald]

En gros pour moi ça dépends d'ou viennent les infos. Si les infos sont exclusivement générées par l'application et un set d'applications qui sont censé marcher ensemble et communiquer de manière fermé (c'est a dire que la communication n'est pas possible 'avec d'autres applis, même si ces applis peuvent connaitre le protocole de communication), alors des assertions suffisent parceque si il y a un probleme avec la cohérence des données, ça viens forcément de l'appli elle même, et il faut le corriger.

Si les données peuvent venir de l'exterieur (plus courant) alors mieu vaut utiliser des exceptions OU BIEN, si on peut s'attendre a des erreurs et qu'on peut les gérer immédiatement, juste les gérere et avoir un systeme (qui peut être a part) pour enregistrer qu'il y a eu un probleme (log ou stack d'erreurs accessibles au runtime, ou autres solutions).

J'ai vu ce principe appliqué dans la vraie vie (application bancaire). C'est un aller simple pour l'enfer vert...avoir des assert revient à ignorer les erreurs en prod. Redresser une base de donnée de prod tordue ça se fait, mais c'est atrocement difficile, et je te parle même pas des risques juridiques pour certains types de données. Après je te rassure, quand on prend une exception en prod tout le monde est douloureusement conscient qu'il faut corriger l'appli. Et au moins il en est conscient AVANT d'avoir corrompu des comptes en banques et autre données précieuses

[Joel F]

T'es en train de me dire que les mecs en bancaire ne code pas du code ACID ?

[therwald]

T'es en train de me dire que les mecs en bancaire ne code pas du code ACID ?

Ils devraient. Mais au final ça dépend qui...par exemple ceux qui prennent pas ces besoins de sécurité des données assez au sérieux qui disent "pas d'exception parce que ces connards d'appelants ont qu'à coder proprement" aboutissent à ne pas respecter ces principes...et rassure toi je leur donne tort.