Een stiefkind genaamd "Javascript Exceptiehandling"

Is het jou weleens opgevallen dat het gebruikelijk is om bij webapplicaties keurig de "serverside" foutmeldingen af te vangen maar dat dit nooit het geval is met "clientside" foutmeldingen?

Deze "serverside" afhandeling bestaat meestal uit de volgende functionaliteit:

• notificieren, vaak per e-mail, over de foutmelding en haar details (innerexceptions, details etc.)
• rapporteren over de hoeveelheid en soort foutmeldingen;
• automatisch aanmaken van een "bug" melding in het "bugtrackingsysteem"

Foutmeldingen die echter "clientside" optreden wat dit betreft volledig overgelslagen. Geheel onterrecht als je het mij vraagt want we kennen allemaal de situatie waarbij we niet verder kunnen met het gebruik van een website door een javascript fout. En dat kost de klant geld!

"Worst Case Scenario": een nieuwe "servicepack" voor Internet Explorer waardoor de javascript code achter een bestelknop niet meer werkt.

Vooralsnog kan ik niet anders dan de conclusie trekken dat de oorzaak hiervan ligt in onwetendheid. Dus hieronder een korte schets van zo'n oplossing.

Oplossing

• Zorg dat bij iedere pagina een de "window.onerror" een eventhandler heeft;
• Deze eventhandler moet dan via xmlHttp een request sturen naar een "ClientSideError.aspx" pagina met alle informatie over de "exceptie"-details;
• Daar moet deze foutmelding op ongeveer dezelfde manier worden afgehandeld als een serverside foutmelding (opslaan, notificeren, rapporteren, bugmelding aanmaken)

Ik heb weleens gedacht om hier een standaard oplossing van te maken, in de trant van een JavascriptErrorReporter (merk op dat het woord Javascript hier niet helemaal juist is maar des te herkenbaarder). Voor alsnog niet de tijd voor genomen, maar wie weet.