[javascript] javascript errors opvangen in safari

[js303]

met ms ie kun je javascript errors opvangen mbv "window.onerror" en bijv. opslaan in een debug-log of -db zodat niet alleen de client maar ook de developer te weten komt wat er waar misgaat.

vooralsnog heb ik geen oplossing hiervoor gevonden in safari. weet iemand of hier wel een event of functie voor bestaat?

[crisp]

window.onerror zou ook gewoon in safari moeten werken, maar hoe wil je dat naar een log gaan schrijven?

[TeeDee]

crisp schreef op 15 juli 2004 @ 19:03:
window.onerror zou ook gewoon in safari moeten werken, maar hoe wil je dat naar een log gaan schrijven?

debug-log of -db

verder: http://www.quirksmode.org/js/events_compinfo.html#misc

M.a.w.: nee

[ Voor 3% gewijzigd door TeeDee op 15-07-2004 19:08 ]

[crisp]

debug-log of db is dat IE-propriety? JS kan van zichzelf echt niet naar een log of database schrijven, niet op de client en niet op de server.

en tsja, als safari het niet ondersteund... je zou alles in try - catch blokken moeten zetten dan...

[js303]

crisp schreef op 15 juli 2004 @ 19:32:
debug-log of db is dat IE-propriety? JS kan van zichzelf echt niet naar een log of database schrijven, niet op de client en niet op de server.

oh sorry voor mijn onvolledige info hierover; wilde hier verder niet over uitwijden aangezien dat o/t zou worden, maar ik bedoelde hiermee gewoon een php scriptje aanroepen (in een iframe of img) die vervolgens een insert op een db doet of een regel aan een textfile toevoegt.

en tsja, als safari het niet ondersteund... je zou alles in try - catch blokken moeten zetten dan...

ja dat is idd een optie, maar dat wordt een hel want dan moet ik alles gaan try-en. de context vd vraag is namelijk dat ik een soort cms-achtige site aan het bouwen ben waar leden zelf blokken content - met daarin js - kunnen toevoegen (gevaarlijk ik weet het maar das ook weer o/t) en dan wil ik evt. js-errors dus kunnen loggen en hierop weer verder anticiperen. die content kan typo's bevatten waardoor oa. een js-functie verkeerd aangeroepen kan worden. maar ik krijg ook weleens vage klachten richting js-errors die ik dan zelf niet kan vinden, dus vandaar dat een dagelijkse automatische mail richting mij met daarin evt. js-errors wel erg handig zou zijn; dit doe ik ook al met php-, pagina-aanroep- en authentication-errors.

[TeeDee]

Las laatst iets over een Gecko plugin schrijven voor Safari. Op die manier zou je eventueel errors kunnen trappen. Beetje omslachtig inderdaad.

Of je zou een eigen error handler kunnen maken, met daarin een try...catch. Dus niet voor elke js-functie een try catch maar 1 try catch met variables die daar naar toe gestuurd worden.

Nog meer info: http://www.paranoidfish.org/notes/2003/05/13/1621

En alles wijst erop dat Safari gewoon geen window.onerror ondersteunt. Safari 1.2 ondersteunt wel een console log, maar daar zal jij niet veel aan hebben.

Ik moet zeggen dat ik dit topic wel ff bookmark, want ik liep er ook al een poosje mee.

Edit: nog een "leuke" hack: http://lists.evolt.org/ar...-Mon-20040315/156870.html

[ Voor 9% gewijzigd door TeeDee op 15-07-2004 21:09 ]

[crisp]

Ik vraag me trouwens af wat precies je insteek is om op deze manier JS fouten op te gaan vangen. Tenzij je complete apps of spelletjes bouwt in DHTML is er meestal sprake van kleine overzichtelijke stukjes code die meestal wel dusdanig uit te ontwikkelen zijn dat de kans op niet-exemplarische fouten toch wel heel klein is, en daarnaast is het good practice om ervoor te zorgen dat sites die toegankelijk dienen te zijn niet afhankelijk zijn van scripting.

[js303]

crisp schreef op 15 juli 2004 @ 22:13:
Ik vraag me trouwens af wat precies je insteek is om op deze manier JS fouten op te gaan vangen. Tenzij je complete apps of spelletjes bouwt in DHTML is er meestal sprake van kleine overzichtelijke stukjes code die meestal wel dusdanig uit te ontwikkelen zijn dat de kans op niet-exemplarische fouten toch wel heel klein is, en daarnaast is het good practice om ervoor te zorgen dat sites die toegankelijk dienen te zijn niet afhankelijk zijn van scripting.

ok daar gaat-ie dan, we gaan afdwalen. mijn insteek is als volgt:

het gaat hier om een een cms-achtig systeem om sites mee te bouwen, maar dan op een magazine-achtige manier, waarbij de invoer ook aan de voorkant plaatsvindt, ipv de gebruikelijke backdoor / admin-manier. daarbij gebruik ik erg veel dhtml en javascript voor allerlei tools zoals een text-editor, menu-editor, image scaler, color-picker, spelling-checker, forms-builder etcetera. kortom het begint aardig op een '(web-) applicatie' te lijken whatever je daaronder mag verstaan. (screenshot: http://www.xs4all.nl/~jes303/screenshot.jpg)

btw ik ben met je eens dat in principe de js-code overzichtelijk genoeg moet zijn om evt. bugs makkelijk op te vangen / te traceren / op te lossen. maar theorie en praktijk ontlopen elkaar soms.

enfin, op zich een aardig systeem dus, dat ik in mijn eentje ontwikkel waardoor ik veel tijd kwijt ben in het developpen en het uitvoerig testen op de meest uiteenlopende platformen er weleens bij inschiet (mac en pc IE, safari, mozilla ed) door allerlei redenen.

dan is het heel makkelijk om binnen 1 oogopslag (lees: in 1 e-mail waardoor het gelijk ook ge-archiveerd is) te zien wie inlogt, welke file upload, pagina verwijdert, en een php of javascript error krijgt. ipv in aparte webstats, apache logs te gaan zoeken en speuren, en tijdrovende mailtjes of telefoontjes van collega's / gebruikers te krijgen die vaak niet goed uitleggen wat er misging. zo doe ik dat dus nu al met het php gedeelte, wat echt goed werkt.

magoed, er zullen zeker veel voors en tegens te bedenken zijn voor mijn manier van problem-solving, en er allerlei principe-kwesties en programmeurs-wijsheden op losgelaten kunnen worden. daar ben ik echter nu even niet op uit, want zo blijf je discussieren. vooralsnog houd ik het erop dat js-errors loggen voor mij iig handig is.

nog een "leuke" hack: http://lists.evolt.org/ar...-Mon-20040315/156870.html

ja die kende ik al, maar dat is alleen handig als ik zelf achter een mac zit.

[ Voor 5% gewijzigd door js303 op 15-07-2004 23:44 ]

[Verwijderd]

Volgens mij kan je gewoon het beste Mozilla gebruiken om de errors op te vangen, Safari volgt dezelfde weg als mozilla.

[TeeDee]

Verwijderd schreef op 16 juli 2004 @ 09:23:
Volgens mij kan je gewoon het beste Mozilla gebruiken om de errors op te vangen, Safari volgt dezelfde weg als mozilla.

Uhm, nee hoor. Safari is gebaseerd op kHTML. Lees jij het topic verder ook?

[Verwijderd]

Die errors loggen heb je ook niet zoveel aan, de meest errors die je over het algemeen krijg zijn bijv. "object expected" en de regelnummering daarvan moet je helemaal gaan uitpluizen.

try en catch zoals Crisp noemde is een goede aanpak om runtime errors af te vangen, je kunt ze zelf throwen indien je dit wilt. Voor initialisatie is het niet voldoende, maar imo komt alles toch wel neer op netjes scripten en de zooi achter je op ruimen.

Qua debugging is Javascript niet zo sterk uitgerust, dus het komt echt aan op secuur en verstandig werken.

Je zou zelfs iets kunnen doen alla om safari te patchen

[code]
window.prototype.onerror = function(e){
alert(e);
}
[code]

[ Voor 12% gewijzigd door Verwijderd op 16-07-2004 10:21 ]

[Verwijderd]

TeeDee schreef op 16 juli 2004 @ 09:58:

Uhm, nee hoor. Safari is gebaseerd op kHTML. Lees jij het topic verder ook?

nee ik lees nooit een topic als ik antwoord. Verder staat er in de UA string like gecko, ik weet ook wel dat Safari gebaseerd is op khtml, echter ze kiezen er voor om de implementaties die mozilla reeds heeft te volgen en niet die van IE (bv. XMLHttpRequest), daardoor zullen javascript fouten in Mozilla ook optreden in Safari...

[js303]

Verwijderd schreef op 16 juli 2004 @ 10:15:
Die errors loggen heb je ook niet zoveel aan, de meest errors die je over het algemeen krijg zijn bijv. "object expected" en de regelnummering daarvan moet je helemaal gaan uitpluizen.

das waar ja, maar dan nog is het fijn om enigszins inzicht te krijgen in evt. errors waar ik zelf nog niet tegenaan gelopen was.

try en catch zoals Crisp noemde is een goede aanpak om runtime errors af te vangen, je kunt ze zelf throwen indien je dit wilt. Voor initialisatie is het niet voldoende, maar imo komt alles toch wel neer op netjes scripten en de zooi achter je op ruimen.

ja zitten een aantal nadelen aan try-catch:
- lastiger te implementeren dan bijv. window.onerror (voordeel van try-catch is dan weer wel dat script verder uitgevoerd wordt)
- geeft geen regelnummer terug (voor zover ik de documentatie erover heb nageslagen)
- heb gelezen op http://www.planet-source-...p?txtCodeId=2957&lngWId=2 (link werkt niet altijd, wellicht een overbelaste server!) dat code binnen een try statement - iig in Java - trager uitvoert:

When you declare a try/catch block in Java you cause the compiler to create “protected zones” of execution which require the runtime to do boundary checks and create further processing for the system. You are not making the program more stable by doing this, you are making it many times slower!

of dit dan ook zo in js is weet ik niet, heb zelf nog geen test gedaan hiermee, maar kan me voorstellen dat je er idd spaarzaam mee moet omgaan.

Qua debugging is Javascript niet zo sterk uitgerust, dus het komt echt aan op secuur en verstandig werken.

Je zou zelfs iets kunnen doen alla om safari te patchen

[code]
window.prototype.onerror = function(e){
alert(e);
}
[code]

ja en dan, het gaat er toch om dat er een trigger plaatsvindt zodra er een js-error plaatsvindt? grapje zeker!

[Bosmonster]

Hmm dus als je een javascript error hebt dan genereer je een aanroep naar PHP met javascript... En wat als je script stopt/in de soep loopt door de error? En er verder dus geen javascript meer wordt uitegevoerd?

[crisp]

in sommige gevallen is try-catch toch echt wel goed te misbruiken om juist performancewinst te behalen; zoals bijvoorbeeld in het volgende geval:

JavaScript:

function foo(x,y) {

  try {
    return someArray[x][y];
  }
  catch (e) { return 0; }

}

eerst checken of x een geldige index is, en vervolgens nog eens checken of y daarbinnen een geldige index is kost meer tijd dan deze try-catch constructie

[js303]

Bosmonster schreef op 16 juli 2004 @ 12:36:
Hmm dus als je een javascript error hebt dan genereer je een aanroep naar PHP met javascript... En wat als je script stopt/in de soep loopt door de error? En er verder dus geen javascript meer wordt uitegevoerd?

bijv. zoiets:

HTML:

<html>
    <head><script language="JavaScript" type="text/javascript"><!--

        window.onerror = logError;

        function logError(sMsg,sUrl,sLine) {

            str = "Er is een scriptfout opgetreden.\n"
                + "\nFout: " + sMsg
                + "\nRegel: " + sLine
                + "\nURL: " + sUrl
                + "\n\nWilt u deze fout rapporteren aan de grote baas?";

            if (confirm(str)) {
                window.log.location.href = "http://www.google.com/search?q=javascript+"+escape(sMsg);
                return true;
            } else {
                return false;
            }
        }

    //--></script></head>
    <body>
        <div><a href="javascript:void(opzettelijkeFout())">Klik hier om een foutje te genereren</a></div>
        <div><iframe name="log" src="about:blank" style="width: 100%; height: 50%; margin-top: 20px;"></iframe></div>
    </body>
</html>

wat overigens een grote hiaat laat zien, namelijk dat het regelnummer waarin de fout voorkomt op 1 staat aangezien hij inline wordt aangeroepen (vanuit de a href), waardoor het nauwelijks te debuggen is. maw weinig nuttige informatie eigenlijk, zoals Gordijnstok al wijs aangaf.

crisp schreef op 16 juli 2004 @ 12:41:
in sommige gevallen is try-catch toch echt wel goed te misbruiken om juist performancewinst te behalen; zoals bijvoorbeeld in het volgende geval:
...
eerst checken of x een geldige index is, en vervolgens nog eens checken of y daarbinnen een geldige index is kost meer tijd dan deze try-catch constructie

hmmm, das waar, zo ver had ik nog niet gedacht.

[ Voor 81% gewijzigd door js303 op 16-07-2004 15:54 ]

[Verwijderd]

crisp schreef op 16 juli 2004 @ 12:41:
in sommige gevallen is try-catch toch echt wel goed te misbruiken om juist performancewinst te behalen; zoals bijvoorbeeld in het volgende geval:

Het is uit puristisch oogpunt denk ik niet de manier om try catch voor te gebruiken Het is primair bedoeld als error handling, niet niet als == NULL functie

[Verwijderd]

Je kan een superfunction schrijven met try {} catch(e) {}, kan je meteen exceptions throwen.

window.onerror zuigt, dan die abort meteen het hele script en dat wil je misschien niet.

try { // superblock hier alles gewoon tussen rammen }

catch(e) { schrijf naar weet ik veel waar }

easy as hell, cheaper then dell.

[Verwijderd]

Als aanvulling op mijn vorige post:

try { //superblock }

catch(e) {

gebruik xmlhttp om errors te posten naar bijv een php/asp pagina.
zie je niets van, gebeurt allemaal achter de schermen.

}