Ha a szerver oldali hibákat nem kezeljük le külön, akkor nehézkes az Ajax hívások között megtalálni, hogy pontosan hol is vesztettük el az irányítást. IE alatt kifejezetten rémálom.
Nem várt elem: ')' a 4816-os sorban. Ha nem használtad még kellően sokat az ExtJS-t, akkor nem biztos, hogy beugrik ebből, hogy itt bizony JSON parser hiba lépett fel. :) A JSON hiba meg nem azért történt, mert a kliens ne tudná feldolgozni az JSON adatokat, hanem mert az adatok helyett valójában egy hibaüzenet érkezett.
Vegyünk egy egyszerű példát. Két szám hányadosát szeretnénk szerver oldalon kiszámolni. (hosszú gondolkodás után ez volt a legegyszerűbb példa:)
Kliens oldalon:
url: 'osztas.php',
params: {
a: 6,
b: 2
},
success: function (response) {
var t = Ext.decode(response.responseText);
Ext.Msg.alert('', t.a + ' / ' + t.b + ' = ' + t.hanyados);
}
});
Szerver oldalon:
'a' => $_REQUEST{'a'},
'b' => $_REQUEST{'b'},
'hanyados' => $_REQUEST{'a'} / $_REQUEST{'b'}
)));
Tökéletesen működő példaprogram. :)
Ám, ha a második paraméter helyére nullát írunk, akkor jönnek a problémák...
Először a szerver oldalt egészítsük ki:
A lekezeletlen hibákat kapjuk el. Ezt itt most rendkívül leegyszerűsítem, valóságban érdemes fájlba is naplózni, különbséget tehetünk Ajax és normál hívás között, formázhatunk, további infókat is átadhatunk, egyes hibákat figyelmen kívül hagyhatunk stb.
$msg = 'ErrorCode: '.$errorCode.'<br />';
$msg.= 'ErrorMsg: '.$errorMsg.'<br />';
$msg.= 'File: '.$file.'<br />';
$msg.= 'Line: '.$line.'<br />';
header('HTTP/1.1 500 Internal Server Error');
die($msg);
}
set_error_handler('error_handler');
Egy dolgot emelnék ki csupán, hogy 500-as hibakódot adtunk ki, azaz a szerver visszautasítja a kérést! Ez a kód fusson le a nullával való osztás előtt.
Kliens oldalon is kezeljük le a hibás Ajax hívásokat:
if (response.status === 500) {
Ext.Msg.alert(response.statusText, response.responseText);
}
});
Várakozásnak megfelelően nem lekezeletlen JS hibát kapunk, hanem egy üzenet ablakban a PHP hibát. :)