Pazns a écrit 72 commentaires

En C++, ou bien en programmation de manière générale ?
En C++, pour commencer, je ne voudrais pas faire de trop grandes généralités sur des langages que je ne connais pas.
Même si je pense que de manière générale les exceptions devraient rester des outils spécifiques utilisés quand nécessaire, et ne pas être des outils généraux utilisés quand possible.

Avec les exceptions tu peux traiter tout de suite, comme avec les codes d'erreurs, lorsque c'est pertinent.
Tu peux aussi traiter plus loin (et regrouper les traitements d'erreur plutôt que les multiplier) lorsque c'est pertinent (et le 'trimballage' de contexte sera plus facile, car le langage t'aide).

En théorie, sûrement. Mais dans les faits ? Est-ce toujours possible de traiter dans les couches supérieures ?
Il faut identifier quelles valeurs seront nécessaires à la correction, où elles ont encore un sens, faire attention à leur durée de vie, …
Des problèmes supplémentaires à résoudre, qui peuvent pousser à modifier l'architecture du programme pour la plier autour des erreurs. Faire de la "programmation orientée erreur".
Je ne peux pas m'empêcher de me sentir coupable quand je dois le faire :(

Du code spaghetti pour réparer du code spaghetti, donc :D

Moi aussi, mais avec parcimonie :)

Cela signifie que toutes tes fonctions membres vont devoir vérifier que l'état de l'objet Music est bien ouvert et fonctionnel. Alors qu'un constructeur qui throw rend tout simplement impossible d'utiliser l'objet.

OK, mais ensuite ? Qu'est-ce que le programme doit faire pour continuer ?

Si on s'en tient aux erreurs ayant trait à la programmation pure et pas au système (manque de mémoire, par exemple), qu'est-ce qu'une exception apporte ?
On est au même point que si le programme avait tout simplement vérifier le contexte avant de procéder à la construction.

Plus l'échec est tardif dans la construction, plus on va devoir défaire du travail pourtant réussi.
Au lieu de vérifier avant, on tente en espérant que ça passe, mais dans les deux cas de toute façon il faut gérer 1) l'arrêt (throw, …) et 2) l'échec, donc le système d'exceptions n'apporte rien à part un vocabulaire supplémentaire et des algorithmes qui se déroulent de haut en bas mais aussi en travers.

C'est assez curieux quand on voit la réputation du switch-break, et plus généralement des return en milieu de bloc.

En quoi, au final, les exceptions apportent-elles quelque chose à la gestion d'erreur ?

La gestion du problème n'est pas résolue, elle est changée (pourquoi pas?) et même amplifiée puisqu'il faut maintenant gérer du code qui ne s’exécute potentiellement plus en ligne droite de haut en bas mais aussi en traviole.
Gérer des classes d'exception. Trimballer le contexte de l'erreur jusqu'au lieu de correction.

La dernière chose qui me vient à l'esprit pour gérer une erreur, c'est bien du code spaghetti.

Par exemple, si l'utilisateur valide un formulaire en oubliant de remplir un champ obligatoire, une exception est lancée qui remonte jusqu'à cette boucle, affiche un message signalant la nécessité de remplir le champs oublié, et ensuite laisse tout loisir à l'utilisateur de remplir le champ en question, comme s'il ne s'était rien passé.

Ici, l'erreur (le champ de formulaire vide) est attendue.
Étant donné que le champ de formulaire attend les données venant de l'extérieur, le fait qu'il soit vide fait partie de sa définition.
Cela ne dénote pas un échec irrécupérable, gênant l'intégrité du programme.

Utiliser une exception pour gérer un chemin normal de l'algorithme est une pratique à la salubrité très douteuse.

Comment Rust peut interdire les "dangling references" ?

Parfait, j'ai un doute, à part peut-être la poignée…

Le principal problème dans ces "pays cibles" d'Afrique, semble être la température et l'entretien mécanique des bécanes.
Si le bidon résout plutôt bien le second point, j'ai du mal à voir comment le souci de chaleur est réglé, en l'absence de ventilation, ou bien j'ai mal regardé les bidons de l'article ?
Surtout que du vieux matos recyclé, ça chauffe plutôt, ancienne technologie oblige.

Comment ça se passe, rayon isolation électrique ?
La carcasse métallique d'un boitier d'ordinateur ne sert pas qu'à faire moche. N'a-t-elle pas des propriétés radio-électriques utiles ?

Autant d'isolation était vraiment nécessaire ?

C'est une impression ou c'est une mode ces dernières années, segmentation et redondance mémoire à foison, dans les nouvelles technos ?
Surtout autour de Node.js.

Il faudra voir si Wayland apportera une solution sur ce point, j'imagine.
Ça donnerait un truc du genre :
Xfce <-> XWayland <-> Wayland <--> Optimus ?

Ça serait un peu tard, les modèles 1060 ne même pas encore annoncés alors que les lapins en chocolat ne sont déjà plus dans le placard.

C'est vrai, ça va, si Nvidia continue d'aider à ce rythme, on peut espérer un support de la toute récente fournée Pascal pour 2050 ! :D

Pour une "communauté du libre", il faut du libre, des logiciels, mais aussi une communauté, des gens.

Cela ne me choque pas (ou bien moins que le ton énervé de l'article), dans cette optique.

Je ne trouve pas que le « flat design » soit illisible et moche en lui-même.

Seulement, une mauvaise interface l'est peu importe le style graphique qu'elle présente.
Le flat design étant à la mode, j'imagine qu'il doit être un peu victime de son succès et attire plein de pseudo-ergonomistes pas très compétents et/ou flemmards qui se reposent sur la popularité dudit style.

Même si je ne porte pas cette Madame de mon cœur citoyen, il faudrait des preuves avant d'avancer des histoire de pot-de-vin.

Voyez-vous, contrairement aux USA justement, par ici on préfère la présomption d'innocence jusqu'à preuve du contraire à son opposé d'outre-atlantique.

Personnellement, j'aurais plutôt tendance à penser que Mme. Vallaud-Belkacem est incompétence, à défaut de bêtise.
Comme nombre de hauts-fonctionnaires, elle semble être bien plus une (piètre) gestionnaire qu'une réelle experte.

Et on pourra trouver au moins autant d'horreurs et d'absurdités chez Javascript, j'en suis certain.
On va où comme ça ? Pas très loin malheureusement.

Par contre, cet article date quand même de 2007, c'est une preuve un peu ancienne non x) ?
J'aimerais voir l'état actuel du bout de code, pour culture générale.

D'ailleurs on peut remercier Facebook d'avoir pousser Zend à réagir et à sortir des équivalents encore plus rapides =P

C'est un peu gratuit, comme remarque… Et on est même pas vendredi !
À ce compte-là, Ruby On Rails ? Aha :-P
Node.JS ? Du Javascript, bien mieux, vraiment ?

Si c'est un problème de performances, PHP 7 sorti à la fin de l'année les double sur le papier.
Et pour n'importe quelle application le nécessitant, OPCache est là. Direct et efficace.

Pour les différents aspects un peu… "folkloriques" du langage, PHP n'est pas le pire dans le domaine même si effectivement il rappelle parfois les ténors du domaine des langages attardés (Javascript en étant le roi), soyons honnêtes.
Ces deux-là partagent d'ailleurs une popularité accidentelle, historiquement. J'imagine que ça doit être lié.

Disclaimer : fanatique de PHP.

D'ailleurs, Desura coule écoutilles grandes ouvertes, ou c'est juste une impression ?

J'espère que le travail autour de l'intégration du catalogue de Steam dans Gnome Logiciels sera fait avec attention et personnalisation ainsi que généralisation…

« On » hurlait quand Ubuntu faisait une intégration un peu facile vers Amazon.
Même si ici le cas est un peu différent, je trouve qu'éthiquement/moralement on peut y retrouver des points communs.
Je manque de détails techniques pour me faire une idée précise, ceci dit.

Pour rester dans le thème de l'adaptabilité, Opus est peut-être plus pertinent que Ogg/Vorbis face à MP3.

Cependant je ne connais pas bien Vorbis, je peux me tromper.

Soit, la prochaine fois je me servirai de la balise consacrée.

Sans rancune :-P ?

Un peu d'humour :

https://xkcd.com/927/
Je pense que c'est de circonstance ;-)

Hm, rappelez-moi la différence entre "data-driven" et "système à entité" ?