Thursday, October 06, 2005
Teaching exception handling in C++
I'm teaching my course on exception handling in C++ at a VoIP company, and that brought some reflections to my mind. Looking back, in the beginning exception handling was a mysterious concept for most programmers: Tom Cargill played an essential role by pointing out, in his now historical "Exception Handling: a False Sense of Security"(C++ Report, November/December 1994), how little we knew at the time about the subject.
More than 10 years later, we definitely know more. Scott Meyers and Herb Sutter have published papers and books that pretty much summarize most of what we know about the mechanic of exception safety. What seems to be missing is a good paper documenting a design approach to exception safety, and in particular, how a family of smart pointers should (or must :-) be defined and used right at the design level, from UML models up. I gave some hints in my "UML 2 Manuale di Stile", but that's far from being a comprehensive reference on the subject (it won't be the right place, anyway).
What is curious is that this overdue paper would have no natural place to appear (in print). Years ago, the C++ Report or the JOOP would have been two perfect journals for such an article. Today, we only have the C++ User's Journal left, and they don't publish articles on "methods". They do have columns talking about methods (somehow), but a column, by definition, is not open to contribution. Sure, there is always the web, or some conference proceedings, but in both cases, the visibility of the paper may not justify the effort spent writing [a good] one. There seems to be no mainstream publication devoted to good design techniques, from class/method level to architectural level. I've recently seen sensible papers featured in technology-centric journals, but that's more the exception :-) than the rule. Interesting papers are published on IEEE periodicals once in a while, but I won't consider that as "mainstream". I guess there is no economy of scale, both on the reader's and on the author's side (excluding the ever-abundant theoretical papers). Reasons and implications of that form a huge, self-sustaining :-) cause/effect graph which would be so fun to draw...
More than 10 years later, we definitely know more. Scott Meyers and Herb Sutter have published papers and books that pretty much summarize most of what we know about the mechanic of exception safety. What seems to be missing is a good paper documenting a design approach to exception safety, and in particular, how a family of smart pointers should (or must :-) be defined and used right at the design level, from UML models up. I gave some hints in my "UML 2 Manuale di Stile", but that's far from being a comprehensive reference on the subject (it won't be the right place, anyway).
What is curious is that this overdue paper would have no natural place to appear (in print). Years ago, the C++ Report or the JOOP would have been two perfect journals for such an article. Today, we only have the C++ User's Journal left, and they don't publish articles on "methods". They do have columns talking about methods (somehow), but a column, by definition, is not open to contribution. Sure, there is always the web, or some conference proceedings, but in both cases, the visibility of the paper may not justify the effort spent writing [a good] one. There seems to be no mainstream publication devoted to good design techniques, from class/method level to architectural level. I've recently seen sensible papers featured in technology-centric journals, but that's more the exception :-) than the rule. Interesting papers are published on IEEE periodicals once in a while, but I won't consider that as "mainstream". I guess there is no economy of scale, both on the reader's and on the author's side (excluding the ever-abundant theoretical papers). Reasons and implications of that form a huge, self-sustaining :-) cause/effect graph which would be so fun to draw...
Comments:
<< Home
A mio avviso ci sarà sempre meno spazio per pubblicazioni riguardanti design efficiente perchè il design assume sempre meno importanza (xp programming, time to market, ecc.) con conseguente contrazione del tempo dedicato agli aspetti considerati "non core" (come ad esempio l'exception handling).
A proposito di exception handling: i linguaggi moderni, e non solo (VB), ci hanno abituato ad inquinare il nostro codice con le logiche di gestione dell'errore.
Domanda a proposito di pubblicazioni: non ti sembra che in giro ci siano un po' troppi papers pubblicati da chi, e mi riferisco alla scena accademica, ha esigenza di pubblicazione per motivi di dottorati, borse, ecc.? Ricordo che quando mi documentai (passato remoto :-) per redarre la mia tesi di laurea trovai decine di pubblicazioni che altro non erano che furbe specializzazioni di tecniche o algoritmi già noti in letteratura per particolari, anzi particolarissimi casi (ma questi papers avevano un bel page header con il logo di qualche prestigiosa univeristà).
A proposito di exception handling: i linguaggi moderni, e non solo (VB), ci hanno abituato ad inquinare il nostro codice con le logiche di gestione dell'errore.
Domanda a proposito di pubblicazioni: non ti sembra che in giro ci siano un po' troppi papers pubblicati da chi, e mi riferisco alla scena accademica, ha esigenza di pubblicazione per motivi di dottorati, borse, ecc.? Ricordo che quando mi documentai (passato remoto :-) per redarre la mia tesi di laurea trovai decine di pubblicazioni che altro non erano che furbe specializzazioni di tecniche o algoritmi già noti in letteratura per particolari, anzi particolarissimi casi (ma questi papers avevano un bel page header con il logo di qualche prestigiosa univeristà).
# posted by 
: 10:52 PM
: 10:52 PM
Il piacere di essere ascoltati
Sono un estimatore di WinZIP (di cui posseggo regolare licenza) ed ultimamente sto provando la versione 10.0 in versione Beta. Avevo fatto notare al team di sviluppo che la nuova funzionalità (Job schedule), nel caso si scegliesse "dayly" poteva essere migliorata con la possibilità di scegliere i giorni (probabilmente a pochi interessa eseguire backup di sabato e domenica, se non si lavora). Ho avuto il piacere di essere stato accontentato. Veramene avevo chiesto anche di poter considerare una tabella di festività annuali, ma non si può avere tutto nella vita :-)).
PS Non ho ancora letto l'articolo e può essere che poi faccia un post più attinente.
Sono un estimatore di WinZIP (di cui posseggo regolare licenza) ed ultimamente sto provando la versione 10.0 in versione Beta. Avevo fatto notare al team di sviluppo che la nuova funzionalità (Job schedule), nel caso si scegliesse "dayly" poteva essere migliorata con la possibilità di scegliere i giorni (probabilmente a pochi interessa eseguire backup di sabato e domenica, se non si lavora). Ho avuto il piacere di essere stato accontentato. Veramene avevo chiesto anche di poter considerare una tabella di festività annuali, ma non si può avere tutto nella vita :-)).
PS Non ho ancora letto l'articolo e può essere che poi faccia un post più attinente.
# posted by : 9:40 AM
: 9:40 AM
Punto 1) C'è ancora qualche lato oscuro per me nelle eccezioni come ad esempio la specifica. boost ad esempio non la usa e tu stesso consigli di farla solo per le funzioni più importanti! visto che le exceptions non sono checked come in java mi chiedo anch'io che necessità c'è di specificarle anche per i metodi più importanti!!
Punto 2) Il mondo dell'informatica si velocizza sempre di più e il management vuole soluzioni ai problemi che hanno, non gliene frega niente se il codice è exception safe (tu stesso hai citato da qualche parte il good enough software :-))
Punto 3) sul fatto che i periodici dell'IEEE non siano il mainstream hai ragione, pensa che molti non li leggono più nemmeno all'università (non sanno nemmeno che esistono)
Just my 2 cent
Punto 2) Il mondo dell'informatica si velocizza sempre di più e il management vuole soluzioni ai problemi che hanno, non gliene frega niente se il codice è exception safe (tu stesso hai citato da qualche parte il good enough software :-))
Punto 3) sul fatto che i periodici dell'IEEE non siano il mainstream hai ragione, pensa che molti non li leggono più nemmeno all'università (non sanno nemmeno che esistono)
Just my 2 cent
# posted by : 5:07 PM
: 5:07 PM
Rispondo principalmente a Davide perche' in questo modo riesco a fare alcuni riferimenti mirati, conscio che per gli altri non saranno cosi' chiari :-).
Come ormai ho detto piu' volte, il design di per se' non e' un valore (sorry :-). Lo e' nella misura in cui contribuisce al successo del prodotto e dell'azienda, ad es. aumentando il valore che il prodotto ha per chi lo utilizza. E' compito nostro, di bravi progettisti, usare al meglio le tecniche che conosciamo, tenendo ben presenti il time to market ecc ecc. Esempio concreto: se pensi all'ultima macchina a stati che abbiamo disegnato insieme, si poteva accorciare il time to market mettendosi subito a programmare? A mio avviso no. Rimanendo vicini al subject del mio post, una volta appresi per bene i concetti di strong, weak e shared pointer, si riduce il time to market programmando senza progettare ownership e lifetime degli oggetti? A mio avviso no.
Per Fulvio: i manager hanno tutte le ragioni di chiedere soluzioni rapide ai problemi che hanno. I buoni progettisti devono imparare a integrare queste necessita' nel processo di sviluppo e a negoziare soluzioni win-win, per quanto questo sia meno appealing :-) per la mentalita' nerd-like :-). Poi certe applicazioni corporate sono intrinsecamente usa e getta, e qui pratiche come XP non vanno cosi' male, anche se (ovviamente) in molti casi sono usa e getta perche' manca la capacita' di astrazione sufficiente e soprattutto, ci manca la capacita' di stendere un piano dimostrabile dei costi e dei valori delle diverse soluzioni, al di la' delle pontificazioni tecniche...
Post a Comment
Come ormai ho detto piu' volte, il design di per se' non e' un valore (sorry :-). Lo e' nella misura in cui contribuisce al successo del prodotto e dell'azienda, ad es. aumentando il valore che il prodotto ha per chi lo utilizza. E' compito nostro, di bravi progettisti, usare al meglio le tecniche che conosciamo, tenendo ben presenti il time to market ecc ecc. Esempio concreto: se pensi all'ultima macchina a stati che abbiamo disegnato insieme, si poteva accorciare il time to market mettendosi subito a programmare? A mio avviso no. Rimanendo vicini al subject del mio post, una volta appresi per bene i concetti di strong, weak e shared pointer, si riduce il time to market programmando senza progettare ownership e lifetime degli oggetti? A mio avviso no.
Per Fulvio: i manager hanno tutte le ragioni di chiedere soluzioni rapide ai problemi che hanno. I buoni progettisti devono imparare a integrare queste necessita' nel processo di sviluppo e a negoziare soluzioni win-win, per quanto questo sia meno appealing :-) per la mentalita' nerd-like :-). Poi certe applicazioni corporate sono intrinsecamente usa e getta, e qui pratiche come XP non vanno cosi' male, anche se (ovviamente) in molti casi sono usa e getta perche' manca la capacita' di astrazione sufficiente e soprattutto, ci manca la capacita' di stendere un piano dimostrabile dei costi e dei valori delle diverse soluzioni, al di la' delle pontificazioni tecniche...
<< Home
