On parle de C#, y'a un système d'exception qui peut être intercepté par la VM : et un message d'exception est autrement plus complet, précis et enrichi qu'un simple numéro de retour .
Une terminaison anormale d'un rpogramme ne veut pas forcément dire qu'une exception a été retournée et remontée jusqu'à la VM. En Java celà s'apelle un code rouge. Un exemple simple est quand suite à une destruction un peu trop hative de certains objets on se retrouve à "perdre" des objets fondamentaux à l'execution du programme. Dans 99,99% des ca son va remonte rune erreur, mais j'ai eu le cas d'un programe qui donait toute les apparences de s'executer proprement mais qui en fait se vautrait à un moment, perdait la procédure de boucle et se fermait (nettoyage par le garbage collector des objets inateignable) en apparence proprement.
Je pense qu'un cas similaire peut être codé en .Net pour peu que l'on se penche un peu sur le problème.
mais le code C# ou Java est censé être indépendant de ces considérations de "bootstrapping" visant à intégrer l'exécutable dans son environnement.
En théorie c'est vrai pour Java, en pratique quand on veut faire dialoguer deux threads ou deux processus il y a des fois on a des surprises d'une VM X sur un système x86 à la même VM X sur un système Solaris (vécu inside) . La plupart de ces problèmes ont étés plus ou moins résolus aujorud'hui. Mais de temps en temps ca ressurgit.
Par contre C# est indépendant de la plateforme, mais surement pas du "COM WRAPPER". Comme tu le dis si bien C# a été conçu pour s'intégré très bien avec les objets COM, pour peu que l'on utilise le wrapper par défaut de Microsoft.
Mais même si l'on utilise le wrapper Microsoft on peut avori des surprises. J'ai eu deux collègue squi se sont arrachés les cheveux pendant des semaines sur un programme qui appelait un objet COM en call-back pour les tests d'appoints, mais qui était appelé en natif par l'objet COM lors du fonctionnement normal. Dans ces cas là la déclaration des fonctions compte ennormément, or une des fonctions (pas main, le connecteur base de données) avait deux signatures différentes suivant que l'objet COM appelait le programme ou l'inverse.
Au final il leur a fallu un bon moment pour comprendre pourquoi quand ils utilisaient les fonctions pour tests d'appoints le wrapper finissait par partir en vrille au bout d'un moment.
Je ne connais pas avec précision leur qualité en tant que devoleppeur, et donc je ne peux pas dire si ils ont commis une erreur de débutant ou non. Mais je sais que les objets COM 1.5 ont des procédures d'appels et de référencement très bas niveau, et que si on arrive à gruger le wrapper, on finira par avoir un chouette bazar parceque si le wrapper dit oui, dérrière on attaque le système direct.
Personellement même en Java je fais des "public static int main" ca ne coute rien et c'est utile plus souvent qu'on pourrait le penser.
[^] # Re: On va encore dire que je suis un raleur mais...
Posté par Jerome Herman . En réponse au journal Des nouvelles de Gnome. Évalué à 2.
Une terminaison anormale d'un rpogramme ne veut pas forcément dire qu'une exception a été retournée et remontée jusqu'à la VM. En Java celà s'apelle un code rouge. Un exemple simple est quand suite à une destruction un peu trop hative de certains objets on se retrouve à "perdre" des objets fondamentaux à l'execution du programme. Dans 99,99% des ca son va remonte rune erreur, mais j'ai eu le cas d'un programe qui donait toute les apparences de s'executer proprement mais qui en fait se vautrait à un moment, perdait la procédure de boucle et se fermait (nettoyage par le garbage collector des objets inateignable) en apparence proprement.
Je pense qu'un cas similaire peut être codé en .Net pour peu que l'on se penche un peu sur le problème.
mais le code C# ou Java est censé être indépendant de ces considérations de "bootstrapping" visant à intégrer l'exécutable dans son environnement.
En théorie c'est vrai pour Java, en pratique quand on veut faire dialoguer deux threads ou deux processus il y a des fois on a des surprises d'une VM X sur un système x86 à la même VM X sur un système Solaris (vécu inside) . La plupart de ces problèmes ont étés plus ou moins résolus aujorud'hui. Mais de temps en temps ca ressurgit.
Par contre C# est indépendant de la plateforme, mais surement pas du "COM WRAPPER". Comme tu le dis si bien C# a été conçu pour s'intégré très bien avec les objets COM, pour peu que l'on utilise le wrapper par défaut de Microsoft.
Mais même si l'on utilise le wrapper Microsoft on peut avori des surprises. J'ai eu deux collègue squi se sont arrachés les cheveux pendant des semaines sur un programme qui appelait un objet COM en call-back pour les tests d'appoints, mais qui était appelé en natif par l'objet COM lors du fonctionnement normal. Dans ces cas là la déclaration des fonctions compte ennormément, or une des fonctions (pas main, le connecteur base de données) avait deux signatures différentes suivant que l'objet COM appelait le programme ou l'inverse.
Au final il leur a fallu un bon moment pour comprendre pourquoi quand ils utilisaient les fonctions pour tests d'appoints le wrapper finissait par partir en vrille au bout d'un moment.
Je ne connais pas avec précision leur qualité en tant que devoleppeur, et donc je ne peux pas dire si ils ont commis une erreur de débutant ou non. Mais je sais que les objets COM 1.5 ont des procédures d'appels et de référencement très bas niveau, et que si on arrive à gruger le wrapper, on finira par avoir un chouette bazar parceque si le wrapper dit oui, dérrière on attaque le système direct.
Personellement même en Java je fais des "public static int main" ca ne coute rien et c'est utile plus souvent qu'on pourrait le penser.