Un Point sur la Modélisation des Exceptions

HAL Id: lirmm-00106699

https://hal-lirmm.ccsd.cnrs.fr/lirmm-00106699

Submitted on 16 Oct 2006

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of

sci-entific research documents, whether they are

pub-lished or not. The documents may come from

teaching and research institutions in France or

L’archive ouverte pluridisciplinaire HAL, est

destinée au dépôt et à la diffusion de documents

scientifiques de niveau recherche, publiés ou non,

émanant des établissements d’enseignement et de

recherche français ou étrangers, des laboratoires

Un Point sur la Modélisation des Exceptions

Yolande Ahronovitz

To cite this version:

Yolande Ahronovitz. Un Point sur la Modélisation des Exceptions. 05063, 2005, 10 p.

�lirmm-00106699�

YolandeAhronovitz

septembre 2005

Dans uneprésentationauworkshopsurlesex eptionsdeECOOP2000, puisdans un arti lepublié début 2001[AH01℄, nous onstations que lagestiond'ex eptions étaitlargementétudiée danslalittérature,maisquela on eptionproprementdite desex eptions ( ommentlestrouver,lesdé rire, lesorganiser)étaittrès rarement abordée.

Nousproposionsdans epapierunguidepourla on eptiondesex eptionsàpartir desélémentsdumodèleobjetstatique.Nousavonsréalisédepuisun ertainnombre d'investigationspratiques enJava,travaildefondnonen oreabouti.

Parallèlement,nousvoudrionsfairele pointde lasituation a tuelle:est- eque la on eptiondesex eptionsestplusétudiéemaintenantqu'ilya inqans?

Il faut serendre àl'éviden e : il est possible que lesujet intéresse, mais ça ne se traduitpasenpubli ationsqui luiseraiententièrementdédiées.

Parailleurs,lesprogrèsen on eptualisation dessystèmesdegestiond'ex eptions se poursuivent: dupapier de base deR. Miller et A. Tripathi [MT97℄ au dernier workshop sur le sujet àECOOP 2005 [RDKT05℄, où l'on trouve bon nombre de présentationssurlamodélisationdessystèmesdegestiond'ex eptions(dontuneen UML [CGGP05℄),le heminpar ouruestsigni atif.

Or,lorsqu'onveutmodéliserlessystèmesdegestiond'ex eptions,ilfautmettreun peud'ordredans lesex eptionselles-mêmes.

D'où l'idée d'essayerde re enser, dans les arti les sur lagestion d'ex eptions, les boutset mor eauxquiparlentdes atégoriesd'ex eptions,deleurorganisation,de l'artdelesutiliser.

Cesmor eauxtrèsvariésserangentplusoumoinsdanstroisrubriques: lassement des ex eptions suivant divers ritères, onseils et aides pour bien faire, résultats d'expérien esetanalysesdeprogrammes.

Letextequisuit donnelespremiersrésultatsde ere ensement,toujoursen ours a tuellement.

2 À ha un sa lassi ation : les atégories d'ex ep-tions

Comme ledit J. Kiniry dans [Kin03℄, il faut onsidérer e que les ex eptions re-présentent : une stru ture pour gérer les situations anormales imprévisibles, une stru turepourleotde ontrle,ouquelque hoseentrelesdeux?

Suivantlesensverslequelonpen he,les ritèresde lassi ationsontpluttdé rits pardesétatsdusystèmeoureprésentésparunesituationrelativementpré isément modélisée.

Un état anormal Dans leurpapier[MT97℄, R.MilleretA. Tripathi dénissent uneex eption ommeunétatanormaldansun al ul,etidentientquatre auses d'ex eptions :

 une erreur :étatsystèmenonvalideetnonautorisé;  une déviation:étatsystèmenonvalideautorisé;

 unenoti ation:informationàl'appelantquel'étatsystèmepré édentousupposé a hangé;

 unidiome :autres as,oùl'o urren ed'ex eption n'estpasuneanomalie, mais pluttune hoserare.

Compartiments À l'opposé, M.Robillardet G.Murphy[RM00℄, après avoirété débordéspardesex eptionsunpeudésordonnées, her hentunesolutiondansune

ompartiments(subdivisions faitesen fon tion delalogique duprogrammeur), et de xer omplètement les interfa es entre ompartiments. Ils distinguent ensuite trois as:

 lesex eptionsde hautniveau,quisontinter- ompartiments,et sontdon lan ées ensortied'un ompartiment;

 lesbas-niveauouinternes,quisontintra- ompartiment,sontlan éesàl'intérieur d'un ompartiment,et sont enséesêtretraitées àlintérieur;

 siuneex eptioninternenepeutpasêtretraitéedansson ompartiment,onlan e àl'extérieuruneex eptiondehautniveauquilarempla e.

D.Malayeriet J.Aldri h[MA05℄seré lamentdeRobillardet proposentunenotion demodule,ave lamêmeidéededé oupagedulogi iel.

Ils ne semblent ependantpas estimer lagranularité de la même façon.Les deux équipestravaillentenJava,oùilyaunenotiondepa kage.M.RobillardetG.Murphy voient le ompartiment omme un sous-ensemble logique du pa kage, alors que D.MalayerietJ.Aldri hvoientlemodule ommeunregroupementdeplusieurs pa- kages.

Stru ture des Composants Danslemêmeespritd'organisation,maisave une optique diérente,A. Romanosvskyet ses ollègues [GRRX01℄ disentqu'un om-posantsystèmeretourneuneex eptionquandilnepeutpassatisfaireune requête, et lassentlesex eptionsen:

 ex eptions internes: lan éespar le omposantpourinvoquersa propre gestion interne detoléran esauxfautes;

 ex eptions externes subdiviséesen:

 ex eptions d'interfa e : lan éesquand unerequête estnon onforme( e n'est pasle omposantqui lesren ontrequi peutlesgérer);

 ex eptions de défaillan e (failure) : lan ées lorqu'un omposant onstateque, pouruneraisonquel onque,il nepeutpasrendreleservi edemandé.

DynamiquedesComposants Dansunpapierquitraitedegestiond'ex eptions dans les systèmes à base de omposants [SUVD03℄, F. Sou hon et ses ollègues déterminenttrois atégories:

 ex eptions ritiques: ellesdoiventêtretraitéesauplusvite;  ex eptions non ritiques : ellespeuventêtremisesenattente;

 ex eptions on ertées:quandla onjon tiondeplusieursex eptionsmisesen at-tentepermetdediagnostiquerunproblèmeunique,onlan euneseuleex eption, dite ex eption on ertée,qui représente e problème (type d'ex eption présenté dans[Iss01℄).

Systèmes ollaboratifs Ave unenotiond'organisationbaséesurladynamique dusystème,A.Tripathietses ollègues[TKA05℄dénissentdes atégories d'ex ep-tionspourlessystèmes ollaboratifs.Cessystèmes omportentdesmembresquiont des rles àexé uter, d'où une ex eptionRoleMember pourun membre qui quitte son rle de façon inattendue, et une ex eption Obligation pour une opération de rle nonexé utéealorsquelapré onditiond'exé utionest vraiedepuisun ertain temps, à téd'ex eptions plus lassiques (Obje t Binding Ex eption, Appli ation Ex eption).

S énarios Un ritèrede lassi ationtrèsdiérentestretenuparN.Maidenetses ollèguesdans[MMS

+

99℄.Cetarti letraitedes énarios(voirplusdedétailsdansla se tion 3),et s'intéresseaux omportementsanormauxdans lemodèledynamique d'uneappli ation.Ilproposetroisgrandstypesd'ex eptions:

états,objets,a tions,agents);

 ex eptiondepermutation:liéeàlaséquen ed'événementsdus énario:inversion d'événements, répétition in orre te d'un événement, survenue prématurée d'un événement,et ;

 ex eptionproblème:liéeàunévénementouunétatinattenduàl'interfa eentre lesystèmequ'onmodéliseet sonenvironnementexterne.

Synthèse Danstous es exemples(et quelquesautres non ités),on trouveune bellepalette de possibilités de atégorisations, dénies ha unede façon indépen-dante.Ellesontenfaitdeux ara téristiquesremarquables:

 elles ne se ontredisent pas: si ellessont pertinentes pour unmême problème, ellespeuventse roiserouse ompléter;

 elles reètent presque toutes laforte poussée du besoin de modularitéet d'en- apsulation:d'unefaçonoud'uneautre,ellesséparentlesex eptionslo ales,à gérersurpla e,desex eptionsqu'ilfautenvoyersefairegérerailleurs.

3 À tout le monde la même éthique : les onseils et aides pour bien faire

Ces onseilsetaidess'adressent,suivantlesarti les,auxprogrammeurs,aux on ep-teursde langagesde programmation,et aux on epteursdemodèles(il n'yarien pourles on epteursdelangagesdemodélisation,onn'enest pasen orelà).

3.1 Conseils aux programmeurs

Ils s'adressentsurtout,apparemment,auxprogrammeursJava,nonpar equ'ilsse débrouillentmoinsbienquelesautres,maispar equ'ilssontàpeuprèslesseulsà utiliserunlangagequi lesobligeàprendreen omptelesex eptions

1

,queçaleur plaiseounon(voirse tion4).

Unefoishabituésàgérerdesex eptions,ilsonttendan eàvouloirendénir,don les onseilsportentàlafoissurladénitionet lagestiondesex eptions.Ceux ités dans ettese tionne on ernentbiensurqueladénitiondesex eptions.

Dedésormais très lassiques onseilssontdonnésparB.Venners[Ven98℄ :

 prévoirdes ex eptionspourunmauvaisusaged'une lasse,paspourdes hoses normales;

 distinguer les ex eptions de pré ondition (mauvais appel d'une méthode, par exemple) des ex eptions de post ondition (ex : il y a un problème dans une méthodeappelée orre tement);

 dénir desex eptions spé iques(pas d'ex eption fourre-tout uniqueàlan er entoutes ir onstan es);

 lorsqu'ondénituneex eption,prévoir orre tementsielledoitêtre ontrléeou non ( he ked ouun he ked); si elleest ontrlée,le lient est obligé des'en o uper,don ildoitenavoirlesmoyens.

J.Blo h,dans [Blo01℄,donneàpeuprèslesmêmes.

M.Robillard, dans [RM00℄, s'en tient à des onseils de bonne onduite ou de o-héren e élémentaire : do umenter omplètement les interfa es, ne pas utiliser les ex eptionsprédéniesdusystèmepourn'importequoi....

1

Une he ked ex eption doitobligatoirementêtretraitée,soitenlarattrapant, soitendisant expli itementqu'onlarelan e;etun bon nombre d'ex eptionsdusystèmesontde e type.La plupartdeslangagessontplusa ommodants(voirC++)

un tétrèsinquiétant:s'ilsn'apportentpasd'aideàl'identi ationdesex eptions dans une appli ation pré ise, e n'est pas par e qu'ilssupposent que e travail a été fait àlamodélisation,avantde programmer.Bien au ontraire, ilspartent du prin ipequerienn'aétéprévu,etqu'ilfautsedébrouillerauvol.

3.2 Conseils pour les on epteurs de langages de program-mation

Les arti les qui lesprodiguent sontbeau oup plus rares que eux qui s'adressent auxprogrammeurs.

Leplusan ienestlepapierdeR.MilleretA.Tripathi[MT97℄,quiessaied'identier ave pré isionles onitsentrelesexigen esdelagestiondesex eptionsetlesbuts delamodélisation orientéeobjet.

Il nedonne pasde onseils àproprement parler,maisil met enéviden e des pro-priétés qu'au un langage n'implémente ( maissont-elles implémentables?). Parmi es propriétés,uneestla onsistan ed'uneex eption: haqueex eptiondoitavoir unseulsensasso ié,indépendantdel'endroitoùelleestsignalée.

L'arti le deJ.Kiniry [Kin03℄ est undes raresqui s'intéressent àla représentation desex eptions,etnon àleurgestion.

En s'appuyant sur deux langages à points de vue opposés (Java : les ex eptions ommestru turede ontrle,Eiel:lesex eptionspourgérerlessituations impré-visibles),il présenteseptpoints- lés,dontquatresontdes onseils.

Deux de es onseilsportentsurlasémantiquedesex eptions:

 le premier rejoint elui de Milleret Tripathi : une ex eption doit avoir une sé-mantique onsistanteetuniforme;

 le deuxième on ernelesex eptionsutiliséespourreprésenter leserreurssur les assertions:leur on eptionetleursémantiquedoiventapparteniraunoyaudela spé i ationdulangage.

Lesdeuxautres onseils on ernentlareprésentationd'uneex eption:

 elledoitêtre uniforme(pasdeux typesde représentationpossibles, omme 'est le asparexempleenEielave lesnombreset les haînes);

 s'ilexisteunereprésentation ompréhensibleàlafoispourl'hommeetlama hine, elle ne doitpas omporter de parties optionnelles (pasde méthodes pardéfaut qu'onpeutnepasredénir, ommelegetMessagedeJava).

Ces onseils sontassezsimplesàexprimer, mais danslamesure oùils on ernent prin ipalementlasémantique,leurmiseen÷uvren'estpasfor émentfa ile.

3.3 Conseils et aides pour les on epteurs de modèles

Ils'agiti idemodélisationsappuyéessurUML.

Voi id'abordunbrefrappeldenosproprestravaux.Dans[AH01℄,nousavons pro-poséunguidepouraideràl'identi ationd'ex eptionseninspe tantles lasses,les propriétés, lesasso iationset les ontraintesdénies danslemodèleobjetstatique d'uneappli ation.

Ce guide, assortide quelques ajouts au métamodèle UML, permet de re her her touteslespossibilitésd'ex eptionsdé elablesenstatique.

Ce par oursexhaustifdonneunrésultatengénéralvolumineux,quele on epteur doitensuitetrierpourprévoiruniquementlesex eptionsutiles.

onseils.

Un très intéressant travail, omplémentaire duntre, a étéréalisé par N. Maiden etses ollègues[MMS

+

99℄,pouraideràl'identi ationd'ex eptionsdanslemodèle dynamique.

Ils ont misau point unlogi iel de génération et d'utilisation de s énarios,appelé rews-savre.

Onutilise habituellementless énariospoursimulerlafaçondontlefutursystème doit se omporter.Les auteurs de e papiersuggèrentde lesutiliser poursimuler aussi equelefutursystèmenedoitpasfaire.

Pour pouvoir mettre en pla e es s énarios d'anomalies, il faut identier les as d'ex eptions.

N.Maidenetses ollèguesproposentdon une lassi ationdesex eptionsentrois groupes,déjàprésentéei iense tion2.

Pourlesdeuxpremiersgroupes,liésaux omposantsdebase dus énariopourl'un (ex eptionsgénériques),auxdéfautsde séquen edansledéroulementpourl'autre (ex eptionsdepermutation), ilsdonnentdeslistesassezpré isesd'ex eptions ou-rantes.Pourletroisième groupe,liéàdesproblèmesàl'interfa edusystèmeetde sonenvironnementexterne,ils fournissenttouteune série detaxonomies,en fon -tiondesdomainesd'appli ation.

Cesdiérenteslistesettaxonomiessontsto kéesdansunebasededonnéesasso iée ausystèmedesimulation,don l'utilisateurdisposed'unoutilassez omplet.

Ilestàremarquerque esdeuxsystèmessontdesaidesdebase,etquele on epteur est enséutilisersondis ernement,salogique,et sa onnaissan edudomaine. Peut-on espérer une évolution de la re her he vers de véritables systèmes d'aide élaboréepourl'identi ationdesex eptions?

4 La dure réalité du programmeur : résultats d'ex-périen es et analyses de programmes

4.1 Résultats d'expérien e

Un papier de R. Maxion et R. Olszewski [MO00℄ rend ompte d'une expérien e menéeave desétudiants.Ellemontresurtoutquedesprogrammeursqui ollaborent etquiappliquentuneméthodologie ommuneobtiennentdemeilleursrésultatsque s'ils travaillent séparément et regroupent leurs résultats à la n, e qui doit être vraidansd'autresdomainesquelesex eptions.

Une autre onstatation,plusspé iquede e qui nousintéresse,estquebeau oup desprogrammeursde etteexpérien enesaventpastraiterlesex eptionsqu'ilsont eux-mêmeprévues,fauted'avoirréé hià equ'ellesreprésentent.

Ce i rejoint e qui avaitdéjà été onstatédans lase tion3.1 :leprin ipedebase sembleêtre:sedébrouillerauvol.

4.2 Résultats d'analyses de programmes

4.2.1 Analyse de stru ture

Un des problèmes fondamentaux posés par la gestion des ex eptions est qu'elle omplique singulièrement le otde ontrle d'un programme. Le fait de pouvoir, en ari aturant,sautern'importeoùn'importequand, rappellefâ heusementles gotoquiontétésidi iles àmuseleretàen adrer.

grammeetlevisualiser,sansfaired'exé utionee tive.

Parmieux,S.SinhaetM.J.Harrold[SH00℄dé riventtout equ'ilfautajouteraux prin ipaux typesd'analyse deot lassiquespourtraiterlesex eptions(expli ites et syn hrones).

M.Robillard et G.Murphy [RM99℄ proposentun outil plus fa ile à manipuler: le logi iel jexextrait leot d'ex eptiondu texted'un programme Java,et visualise lesstru turestry... at het lesappelspouvantdonnerlieuàex eption.

Danslemêmedomaine,D.Malayeriet J.Aldri h[MA05℄proposentExnJava,qui permet enplus d'agir en réorganisantun peu le ode(il s'agit prin ipalementde bien utiliserlesoutilsfournisparJavapourgérerlesex eptions).

Tous es outils sont faits pour mettre en éviden e la façon dont les ex eptions sontgéréesparunprogramme.Maislesrésultatsqu'ilsfournissent onduisenttout naturellementàs'interrogersurlafaçondontellessontdénies.

4.2.2 Analyse de ontenu

Une autrefaçond'analyserlesprogrammes onsisteàregarder,nonpaslasyntaxe utiliséeparlesprogrammeurspourtraiterlesex eptions,maislasémantiquequ'ils yontmise.

C'est à e travail que se sont attelés D. Reimer et H. Srinivasan [RS03℄ : ils ont étudiél'usagefaitdesex eptionsdanslesappli ationsJavadegrandetaille.

Ce qu'ilsonttrouvéest atastrophique:

 devéritablessottises:ex eptionsrattrapéesave un at hvide,utilisationd'un at h unique pour rattrapertoutes les ex eptions possibles dans unblo try, alorsqu'ellesn'ontau unrapportentreelles(sauflefaitdepouvoirêtrelan ées danslemêmeblo try);

 desdéfautsd'utilisationpatents:handlerslimitésàunmessagesansintérêt, pro-pagationd'ex eptionsàtraversune bonnepartie duprogrammepourlestraiter leplusloinpossibledelàoùellesontétélan ées.

Cessottisesetdéfautsprouventd'abordque,lorsqu'onveutfor erlesprogrammeurs àutiliserdesex eptions,ilslefontmal.Maisilsmontrentaussiunein ompréhension fondamentalede equereprésente uneex eption.

4.3 Dis ussion

Quetirerdetout ela?Detouteéviden e, lapratiquedesex eptionsn'estpasune réussite.

Les tentatives pour rendre obligatoire la gestion des ex eptions (par exemple les he kedex eptions enJava)induisentbeau oupdemauvaistravail.

D'aprèsJ.Kiniry[Kin03℄,quiaétudiéungrandnombredeprogrammes,elles aug-mententlafragilité d'unsystème. Mieuxvautintégrerle pluspossiblede ontrats à la Eieldans un langage : le nombre et la omplexité des ex eptions en seront réduits.

Autreeetnégatif,dit-il: etteobligationdegérerprovoque...l'angoissedes pro-grammeurs (il attribue à ette angoisse les sottises itées i-dessus). Mais il est vraiquegérerdesex eptionsdéniespard'autrespersonnesestunexer i edi ile quand esex eptionssontpeudo umentéesetqueleursigni ationn'estpas laire.

autres spé i ations?Ce peutêtreunmoyend'apprivoiserlesex eptionsenseles appropriant.

Toujours d'après J.Kiniry, laréponse n'est pas évidente. Au vu des résultats ob-tenus, etteobligation despé i ations augmente àlafois laqualité du ode et la produ tivité du développeur quand il s'agit de petits programmes, mais pour de grands projets logi iels on ne gagne à peu près rien en qualité et on perd en produ tivité.

On retrouvelàle problèmede la sémantiquedes ex eptions, ave deux situations signi ativementdiérentes:

 esont euxquiprévoientlesex eptionsquilesgèrent:petitprogramme, appli- ationé riteparunpetitnombredepersonnespro hes;

 on estdans unesituation lient-serveur, oùleserveurlan e lesex eptionset où le lient peut/veutles rattraperou non: laJVM et lesprogrammeursjava,les grandes appli ations où des équipes séparées ollaborentuniquement par inter-fa es.

Danslepremier as,le onta thumainpermetde ompléterlesspé i ations;dans ledeuxième,il fauts'entenirà equiest é rit.

Onretombedon dansleproblèmegénéraldel'é rituredesspé i ations:soitelles sonté ritesdansunlangagetrès odié,et ellesdeviennentsyntaxiques,soit elles sonté ritesdansunlangageunpeuinformel,etellessontoues.Etdansle asdes ex eptions,onaunin onvénientsupplémentaire:aulieudedé rire equ'onveut, il faut ara tériser equiest anormal, equ'onneveutpas.

5 Con lusion

Les tentativespour ernerlanotionformelled'ex eption sedéveloppent.Ilest a -quis que l'ex eptionest un objet, une entité re onnue. Lebesoinde lassi ation, même s'il se traduit en un foisonnement de ritères, est en ourageant. Et la né- essitédemodularitédonneaumoins deux ritèresimpli itementprésentspresque partout: lesex eptionslo alesetlesautres.

À téde estravaux,ontrouvedespréo upationsde on epteursdemodèles,qui her hentàbienidentierlesex eptionsliéesàuneappli ation,etàlesreprésenter leplus lairementpossible.

Et il y aennlapratiquequotidienne des programmeurs.Dans beau oup de as, 'est undésastrequipeutserésumerdefaçonsimple:onne s'o upepasdes ex- eptions,ons'endébarrasse.Ilmanquemanifestementune ulturedel'ex eption: 'est un on eptmal erné,don lamiseen÷uvre n'estpasbonne.

L'étude de lasémantiquedes ex eptions, qui est un ourant depréo upation ré- ent, ommen e à répondre à e problème en ara térisant des besoinsde base : onsistan e,uniformitédusens.

Cet aspe t est fondamental pour l'avenir des ex eptions : même si on progresse beau oup dans la lassi ationdes typesd'ex eptions, et dansl'identi ation des ex eptions d'une appli ation donnée, rien ne sera utile si on n'aboutit pas à des spé i ations lairespourleprogrammeur.

[AH01℄ Y.AhronovitzandM.Hu hard. Ex eptionsinObje tModeling: Fin-ding Ex eptions from the Elementd of the Stati Obje t Model. In Advan es in Ex eption Handling Te hniques, number 2022 in LNCS, pages7793.SpringerVerlag,2001.

[Blo01℄ J.Blo h.Ee tiveJavaProgrammingLanguageGuide.TheJavaSeries. AddisonWesley,2001.

[CGGP05℄ A.Capozu a,B.Gallina,N. Guel,and P. Pelli ione. Modeling Ex- eptionHandling:aUML2.0PlatformIndependentProleforCAA. In WorkshopEx eptionHandlinginObje tOrientedSystems:Developing SystemsthatHandleEx eptions,pages8899.ECOOP2005,july2005. Glasgow.

[GRRX01℄ A.Gar ia,C.Rubira,A.Romanovsky,andJ.Xu.AComparativeStudy of Ex eption Handling Me hanisms for Building Dependable Obje t-Oriented Software. Journal of Systems and Software, 59(2) :197222, november2001.

[Iss01℄ V.Issarny. Con urrentEx eption Handling. InAdvan es inEx eption Handling Te hniques, number2022 in LNCS, pages111127.Springer Verlag,2001.

[Kin03℄ J.R. Kiniry. Ex eptions in Java and Eiel : Two Extremes in Ex ep-tionDesignand Appli ation. InWorkshop Ex eption Handling in Ob-je t OrientedSystems :Towards Emerging Appli ation AreasandNew ProgrammingParadigms,pages2738.ECOOP2003,july2003. Darm-stadt.

[MA05℄ D.MalayeriandJ.Aldri h.Pra ti alEx eptionSpe i ations.In Work-shopEx eptionHandlinginObje t OrientedSystems:Developing Sys-tems thatHandleEx eptions,pages100111.ECOOP 2005,july2005. Glasgow.

[MMS

+

99℄ N. Maiden,S. Mino ha,A. Sut lie,D. Manuel,and M.Ryan. A Co-operative S enario Based Approa h to A quisition and Validation of System Requirements : How Ex eptions Can Help! Intera ting with Computers,11:645664,november1999.

[MO00℄ R. Maxionand R. Olszewski. Eliminating Ex eption Handling Errors withDependabilityCases:aComparative,Empiri alStudy.IEEET ran-sa tionsonSoftwareEngineering,26(9):888906,september2000. Vo-lume"Spe ialSe tiononCurrentTrendsin Ex eptionHandling". [MT97℄ R.Miller andA. Tripathi. Issueswith Ex eption Handling in

Obje t-OrientedSystems. InM. AksitandS. Matsuoka,editors, ECOOP '97 Obje tOrientedProgramming,11thEuropeanConferen e,number1241 inLNCS,pages85103.SpringerVerlag,june1997.

[PAT00a℄ D. Perry,A.Romanovsky,andA. Tripathi, editors. Spe ial Se tion on Current Trends in Ex eption Handling, volume 26 number9 of IEEE Transa tions on Software Engineering. IEEE Computer So iety, sep-tember2000.

[PAT00b℄ D. Perry,A.Romanovsky,andA. Tripathi, editors. Spe ial Se tion on CurrentTrendsinEx eptionHandling-PartII,volume26number10of IEEETransa tions onSoftwareEngineering. IEEEComputerSo iety, o tober2000.

[RDKT01℄ A.Romanovsky,C. Dony, J.L.Knudsen,andA. Tripathi, editors. Ad-van es in Ex eption Handling Te hniques. Number 2022 in LNCS. SpringerVerlag,2001.

Workshop Ex eption Handling in Obje t Oriented Systems : Towards EmergingAppli ationAreasandNewProgrammingParadigms.ECOOP 2003,july2003. Darmstadt.

[RDKT05℄ A.Romanovsky,C.Dony,J.L.Knudsen,andA.Tripathi,editors. Work-shopEx eptionHandlinginObje t OrientedSystems:Developing Sys-temsthat HandleEx eptions.ECOOP2005,july2005. Glasgow. [RM00℄ M.Robillard and G. Murphy. Designing Robust JavaProgramswith

Ex eptions. In D. Rosenblum and J. Knight, editors, Pro eedings of the 8th ACM SIGSOFT international symposium on Foundations of softwareengineering,FSE'00,pages210.ACMPress,november2000. [RM99℄ M.Robillardand G.Murphy. AnalyzingEx eption Flowin Java Pro-grams. InO. Nierstraszand M. Lemoine,editors, ESEG/FSE'99, 7th European onferen e, number 1687 in LNCS, pages 322337.Springer Verlag,september 99. also in Software EngineeringNotes, SIGSOFT, vol.24number6.

[RS03℄ D. Reimer and H. Srinivasan. Analyzing Ex eption Usage in Large JavaAppli ations. InWorkshopEx eptionHandlinginObje tOriented Systems:TowardsEmergingAppli ation AreasandNewProgramming Paradigms,pages1019.ECOOP 2003,july2003. Darmstadt.

[SH00℄ S. Sinha and M.J Harrold. Analysis and Testing of Programs with Ex eptions Handling Constru ts. IEEE Transa tions on Software En-gineering,26(9):849871,september2000. Volume"Spe ialSe tionon CurrentTrendsin Ex eptionHandling".

[SUVD03℄ F.Sou hon,C.Urtado, S.Vauttier, andC.Dony. Ex eptionHandling in Component-BasedSystems: aFirst Study. In WorkshopEx eption Handling in Obje t OrientedSystems : Towards Emerging Appli ation Areas and New Programming Paradigms, pages 8491. ECOOP 2003, july2003. Darmstadt.

[TKA05℄ A. Tripathi, D. Kulkarni, and T. Ahmed. Ex eption Handling Issues in Context AwareCollaborationSystemsfor PervasiveComputing. In WorkshopEx eptionHandlinginObje tOrientedSystems:Developing Systems that Handle Ex eptions, pages 113124. ECOOP 2005, july 2005. Glasgow.

[Ven98℄ B.Venners. Designingwith Ex eptions. Java World, july98. 7pages inele troni publi ationhttp://javaworld. om.