Suite =E0 une astuce que j'avais crois=E9e sur la FAQ C++-lite [1],
j'avais commenc=E9 =E0 factoriser ma gestion des exceptions. Ce qui me
permet de ne pas parasiter mes fonctions d'interface (CORBA), et
autres fonctions de thread, de blocs try-catch plus longs que le corp
utile de la fonction.
Jusque l=E0, tout va bien. Sauf que. Toutes ces fonctions
handleException() se ressemblent beaucoup tout en connaissant des
subtiles variations. Un coup un type d'exception doit circuler sans
=EAtre intercept=E9, un coup d'autres types doivent =EAtre convertis vers un
type tier, etc., etc.
Du coup, je me posais la question d'avoir un truc encore plus
g=E9n=E9rique, quelque chose qui pourrait p.ex. s'utiliser de la sorte:
try {
actions...
} catch (...) {
handleException<
ExceptionToThrow, // vers laquelle on convertit,
possiblement void
TYPE_LIST_2(CORBA::SystemException,
Metier::ErrorCorbaFormat), // exceptions non filtr=E9es
TYPE_LIST_3(Metier::ErrorCppFormat, std::bad_catch,
std::exception)// exceptions =E0 convertir
>
(stringContexte, divers bool=E9ns pour les traces);
}
Ce qui en gros serait =E9quivalent (c=F4t=E9 HandleException) =E0 :
Mon gros probl=E8me est "comment y arriver?". Sans partir sur la
g=E9n=E9ration d'un mini HandleException pour chaque type des TYPE_LIST
(i.e. le catch(...) de chaque HandleException appelant un autre
HandleException o=F9 l'on aurait d=E9pil=E9 un type d'exception de la
liste), ou sans partir sur des macros =E0 profusion, je s=EAche un peu.
(Je ne suis pas s=FBr que la premi=E8re solution usine =E0 gaz soit tr=E8s
efficace, ni tr=E8s maintenable. Quant =E0 la la deuxi=E8me, elle peut
rapidement devenir un cauchemar =E0 debugguer le jour o=F9 cela devient
n=E9cessaire (core)).
Bref, Vous =EAtes-vous d=E9j=E0 pos=E9 ce probl=E8me ? Et si oui, =E0 quelle
conclusion avez-vous abouti?
Ne pourrais-tu pas intégrer une espèce de "langage de script" dans ton code, et tu chargerais un petit outil fait de tes mains de parser et générer le bloc try catch voulu ?
Sinon, je vais réfléchir à ton problème en restant totalement en C++...
Ne pourrais-tu pas intégrer une espèce de "langage de script" dans ton
code, et tu chargerais un petit outil fait de tes mains de parser et
générer le bloc try catch voulu ?
Sinon, je vais réfléchir à ton problème en restant totalement en C++...
Ne pourrais-tu pas intégrer une espèce de "langage de script" dans ton code, et tu chargerais un petit outil fait de tes mains de parser et générer le bloc try catch voulu ?
Sinon, je vais réfléchir à ton problème en restant totalement en C++...
Luc Hermitte
On 15 sep, 20:33, Alp Mestan wrote:
Ne pourrais-tu pas intégrer une espèce de "langage de script" dans ton code, et tu chargerais un petit outil fait de tes mains de parser et générer le bloc try catch voulu ?
Sinon, je vais réfléchir à ton problème en restant totalement en C++...
Bien sûr que si, mais on retrouve toujours une partie des problématiques que l'on connait avec le préprocesseur. (D'ailleurs il s'agit alors d'une phase de pré-processing.) En fait, on a même alors d'autres problématiques de maintenance qui sont peut-être encore plus exarcerbées que lorsque l'on part sur des trucs compliqués qui restent à 100% dans le langage: chaque développeur devra apprendre cette nouvelle syntaxe. La solution à macros n'est déjà pas terrible pour cela, un pré-processing propriétaire me fait encore plus peur (même si cela serait très facile à écrire en perl, et à utiliser en C++)
Autant cette approche ne me choque absolument pas sur des petits trucs comme des tests unitaires, autant dans du gros code métier, cela me perturbe quelque part.
-- Luc Hermitte
On 15 sep, 20:33, Alp Mestan <alpmes...@free.fr> wrote:
Ne pourrais-tu pas intégrer une espèce de "langage de script" dans ton
code, et tu chargerais un petit outil fait de tes mains de parser et
générer le bloc try catch voulu ?
Sinon, je vais réfléchir à ton problème en restant totalement en C++...
Bien sûr que si, mais on retrouve toujours une partie des
problématiques que l'on connait avec le préprocesseur. (D'ailleurs il
s'agit alors d'une phase de pré-processing.)
En fait, on a même alors d'autres problématiques de maintenance qui
sont peut-être encore plus exarcerbées que lorsque l'on part sur des
trucs compliqués qui restent à 100% dans le langage: chaque
développeur devra apprendre cette nouvelle syntaxe. La solution à
macros n'est déjà pas terrible pour cela, un pré-processing
propriétaire me fait encore plus peur (même si cela serait très facile
à écrire en perl, et à utiliser en C++)
Autant cette approche ne me choque absolument pas sur des petits trucs
comme des tests unitaires, autant dans du gros code métier, cela me
perturbe quelque part.
Ne pourrais-tu pas intégrer une espèce de "langage de script" dans ton code, et tu chargerais un petit outil fait de tes mains de parser et générer le bloc try catch voulu ?
Sinon, je vais réfléchir à ton problème en restant totalement en C++...
Bien sûr que si, mais on retrouve toujours une partie des problématiques que l'on connait avec le préprocesseur. (D'ailleurs il s'agit alors d'une phase de pré-processing.) En fait, on a même alors d'autres problématiques de maintenance qui sont peut-être encore plus exarcerbées que lorsque l'on part sur des trucs compliqués qui restent à 100% dans le langage: chaque développeur devra apprendre cette nouvelle syntaxe. La solution à macros n'est déjà pas terrible pour cela, un pré-processing propriétaire me fait encore plus peur (même si cela serait très facile à écrire en perl, et à utiliser en C++)
Autant cette approche ne me choque absolument pas sur des petits trucs comme des tests unitaires, autant dans du gros code métier, cela me perturbe quelque part.
-- Luc Hermitte
Luc Hermitte
On 15 sep, 20:33, Alp Mestan wrote:
Ne pourrais-tu pas intégrer une espèce de "langage de script" dans ton code, et tu chargerais un petit outil fait de tes mains de parser et générer le bloc try catch voulu ?
Sinon, je vais réfléchir à ton problème en restant totalement en C++...
Bien sûr que si, mais on retrouve toujours une partie des problématiques que l'on connait avec le préprocesseur. (D'ailleurs il s'agit alors d'une phase de pré-processing.) En fait, on a même alors d'autres problématiques de maintenance qui sont peut-être encore plus exarcerbées que lorsque l'on part sur des trucs compliqués qui restent à 100% dans le langage: chaque développeur devra apprendre cette nouvelle syntaxe. La solution à macros n'est déjà pas terrible pour cela, un pré-processing propriétaire me fait encore plus peur (même si cela serait très facile à écrire en perl, et à utiliser en C++)
Autant cette approche ne me choque absolument pas sur des petits trucs comme des tests unitaires, autant dans du gros code métier, cela me perturbe quelque part.
-- Luc Hermitte
On 15 sep, 20:33, Alp Mestan <alpmes...@free.fr> wrote:
Ne pourrais-tu pas intégrer une espèce de "langage de script" dans ton
code, et tu chargerais un petit outil fait de tes mains de parser et
générer le bloc try catch voulu ?
Sinon, je vais réfléchir à ton problème en restant totalement en C++...
Bien sûr que si, mais on retrouve toujours une partie des
problématiques que l'on connait avec le préprocesseur. (D'ailleurs il
s'agit alors d'une phase de pré-processing.)
En fait, on a même alors d'autres problématiques de maintenance qui
sont peut-être encore plus exarcerbées que lorsque l'on part sur des
trucs compliqués qui restent à 100% dans le langage: chaque
développeur devra apprendre cette nouvelle syntaxe. La solution à
macros n'est déjà pas terrible pour cela, un pré-processing
propriétaire me fait encore plus peur (même si cela serait très facile
à écrire en perl, et à utiliser en C++)
Autant cette approche ne me choque absolument pas sur des petits trucs
comme des tests unitaires, autant dans du gros code métier, cela me
perturbe quelque part.
Ne pourrais-tu pas intégrer une espèce de "langage de script" dans ton code, et tu chargerais un petit outil fait de tes mains de parser et générer le bloc try catch voulu ?
Sinon, je vais réfléchir à ton problème en restant totalement en C++...
Bien sûr que si, mais on retrouve toujours une partie des problématiques que l'on connait avec le préprocesseur. (D'ailleurs il s'agit alors d'une phase de pré-processing.) En fait, on a même alors d'autres problématiques de maintenance qui sont peut-être encore plus exarcerbées que lorsque l'on part sur des trucs compliqués qui restent à 100% dans le langage: chaque développeur devra apprendre cette nouvelle syntaxe. La solution à macros n'est déjà pas terrible pour cela, un pré-processing propriétaire me fait encore plus peur (même si cela serait très facile à écrire en perl, et à utiliser en C++)
Autant cette approche ne me choque absolument pas sur des petits trucs comme des tests unitaires, autant dans du gros code métier, cela me perturbe quelque part.
-- Luc Hermitte
Luc Hermitte
On 17 sep, 15:36, Luc Hermitte wrote:
[...] Oups. Désolé pour le doublon (fallait pas switcher de proxy)
-- Luc Hermitte
On 17 sep, 15:36, Luc Hermitte <luc.hermi...@gmail.com> wrote:
[...]
Oups. Désolé pour le doublon (fallait pas switcher de proxy)
[...] Oups. Désolé pour le doublon (fallait pas switcher de proxy)
-- Luc Hermitte
Jean-Marc Bourguet
Luc Hermitte writes:
Autant cette approche ne me choque absolument pas sur des petits trucs comme des tests unitaires, autant dans du gros code métier, cela me perturbe quelque part.
Outre ce que tu as deja ecrit, un preprocesseur externe, ca ne me gene pas pour un DSL (Domain Specific Language), en gros quand le nombre de fichiers a traiter est faible. Mais ici ce n'est pas ca, c'est une extension du C++. On ne se trouve plus a programmer en C++, mais en C++-With-My-Own-Extension et la ca me gene plus. Surtout que si on suit cette pente, on se retrouve vite a programmer en C++-With-Alice-And-Bod-And-Charlie-Extensions.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Luc Hermitte <luc.hermitte@gmail.com> writes:
Autant cette approche ne me choque absolument pas sur des petits trucs
comme des tests unitaires, autant dans du gros code métier, cela me
perturbe quelque part.
Outre ce que tu as deja ecrit, un preprocesseur externe, ca ne me gene pas
pour un DSL (Domain Specific Language), en gros quand le nombre de fichiers
a traiter est faible. Mais ici ce n'est pas ca, c'est une extension du
C++. On ne se trouve plus a programmer en C++, mais en
C++-With-My-Own-Extension et la ca me gene plus. Surtout que si on suit
cette pente, on se retrouve vite a programmer en
C++-With-Alice-And-Bod-And-Charlie-Extensions.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Autant cette approche ne me choque absolument pas sur des petits trucs comme des tests unitaires, autant dans du gros code métier, cela me perturbe quelque part.
Outre ce que tu as deja ecrit, un preprocesseur externe, ca ne me gene pas pour un DSL (Domain Specific Language), en gros quand le nombre de fichiers a traiter est faible. Mais ici ce n'est pas ca, c'est une extension du C++. On ne se trouve plus a programmer en C++, mais en C++-With-My-Own-Extension et la ca me gene plus. Surtout que si on suit cette pente, on se retrouve vite a programmer en C++-With-Alice-And-Bod-And-Charlie-Extensions.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Fabien LE LEZ
On Mon, 17 Sep 2007 07:26:50 -0700, Luc Hermitte :
Désolé pour le doublon
Cancel est ton ami...
On Mon, 17 Sep 2007 07:26:50 -0700, Luc Hermitte
<luc.hermitte@gmail.com>: