Discussion :

[Isidore.76]

Bonjour,

Situation, en 3 points :

1/ un site Web développé en ASP.Net (version 3.5 du Framework)

2/ un web.config tel qu’en cas d’erreur une page « Erreur.aspx » est appelée ; cette page affichant un message « sympathique » signalant l’erreur

3/ des appels AJAX (via JQuery) à des pages ; ces pages (via Response.Write()) retournant du javascript ou du HTML

Question :

Avec une telle architecture, comment gérer les situations d’erreur ??

Pour fixer les choses, imaginons un <div> dont le contenu est alimenté via ajax et un appel à une page web retournant du HTML : quelque chose, coté javascript, avec JQuery, comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
$.ajax({
            type: "GET",
            url: 'ajax/PageQuiRetourneDuHTML.aspx',
            contentType: "application/x-www-form-urlencoded",
            dataType: "text",
            data: 'numero_cde=123456',
            success: function(result)
            {
                $("#div_cible").html( result );
            }
        });

Sachant que dans le web.config on trouve une redirection en cas d’erreur, donc quelque chose comme :

<customErrors defaultRedirect="./Erreur.aspx" mode="On">
</customErrors>

De façon tout à fait prévisible, en cas d’erreur suite à l’appel de ‘PageQuiRetourneDuHTML.aspx', c’est le contenu de « Erreur.aspx » qui sera injecté dans le « div_cible », ce qui n’est pas du tout satisfaisant…

Aussi, je me tourne vers vous : comment gérez-vous semblable situation ??

Appeler une simple page via AJAX n’est certes pas la seule méthode possible, elle fût choisie pour sa simplicité de mise en œuvre, cela dit changer est possible, surtout avec un bout de code d’exemple cote client (Javascript) et coté serveur (.net), donc n’hésitez pas à proposer une solution utilisant une architecture légèrement différente (WebMethod ? etc ?).

D’avance, un grand MERCI !

[lutecefalco]

J'utilise pas jQuery pour faire de l'AJAX. Mias à vue de nez, si t'as le key word success, tu dois bien avoir l'équivalent error non?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
$.ajax({
            type: "GET",
            url: 'ajax/PageQuiRetourneDuHTML.aspx',
            contentType: "application/x-www-form-urlencoded",
            dataType: "text",
            data: 'numero_cde=123456',
            success: function(result)
            {
                $("#div_cible").html( result );
            }
        });

[Kaidan]

Mis à part qu'il n'y a pas d'erreur pour JQuery dans ce cas. Du code HTML (de la page Erreur.aspx) est bien retourné. C'est le problème lorsqu'on récupère directement du HTML sans passer par du JSON ou XML : impossible de passer en plus du contenu une variable avec un code d'erreur.

[Isidore.76]

C'est pas faux

Cela dit, et j'aurais été bien inspiré de le préciser, j'avais essayé, mais bien entendu sans succès ! Et pour cause : la page (Erreur.aspx) n'est pas envoyée au navigateur avec un code d'erreur mais avec un code "200" pour "succès", ce qui se vérifie aisément avec Firebug (extension ôh combien utile de FireFox).

Donc, coté javascript, on ne passe pas dans "error" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
$.ajax({
            ...
            success: function(result)
            {
                $("#div_cible").html( result );
            },
            error: function(xhr)
            {
                alert('Hum hum, erreur !');
            }
        });

Auriez-vous une autre idée ?

Vous n'utilisez pas JQuery, mais peu importe, lors de vos "appels AJAX", si l'un d'entre eux vient à échouer, et que vous utilisez la redirection vers une page d'erreur via le Web.Config, alors comment vous en sortez vous ?

D'avance MERCI

[lutecefalco]

C'est pas faux

Cela dit, et j'aurais été bien inspiré de le préciser, j'avais essayé, mais bien entendu sans succès ! Et pour cause : la page (Erreur.aspx) n'est pas envoyée au navigateur avec un code d'erreur mais avec un code "200" pour "succès", ce qui se vérifie aisément avec Firebug (extension ôh combien utile de FireFox).

Donc, coté javascript, on ne passe pas dans "error" :

$.ajax({
...
success: function(result)
{
$("#div_cible").html( result );
},
error: function(xhr)
{
alert('Hum hum, erreur !');
}
});

Auriez-vous une autre idée ?

Vous n'utilisez pas JQuery, mais peu importe, lors de vos "appels AJAX", si l'un d'entre eux vient à échouer, et que vous utilisez la redirection vers une page d'erreur via le Web.Config, alors comment vous en sortez vous ?

D'avance MERCI

Bah avec ASP.NET AJAX, ça se fait en 2 lignes. Mais ça marche qu'avec ASP.NET AJAX ^^

[lutecefalco]

Une solution serait non pas d'appeler une page qui retourne de l'HTML mais un web service qui retourne de l'HTML.
Du coup, plus de problème

[Isidore.76]

@ Kaidan :

Effectivement, pour JQuery, pas d'erreur...

Au pire, il doit être possible de s'en sortir en "analysant" le HTML retourné, à la recherche d'un mot clef, d'une séquence de caractères, etc... qui serait spécifique à la page d'erreur...

Egalement, du coté de la page appelée par AJAX, un Try/Catch permettrait de trapper toutes les erreurs, et en cas d'erreur d'envoyer... quoi...? un tout petit texte d'erreur... ou une chaine vide!...

Pour l'instant, retourner une chaine vide en guise de HTML et générer un mail aux administrateurs du site, voilà la solution qui me semble la plus acceptable, en l'état...

Est-ce que quelqu'un aurait une meilleure idée ?

[Kaidan]

Quel comportement est-ce que tu voudrais avoir au fait ?

[Isidore.76]

Une solution serait non pas d'appeler une page qui retourne de l'HTML mais un web service qui retourne de l'HTML.
Du coup, plus de problème

La page qui retourne du HTML utilise un objet en cache, dans le cache de l'application. Est-ce qu'un service Web peut accéder au cache ?

En cas d'erreur dans le service Web (une erreur non prévue dans un try/catch), que "retourne" le service web ? En quoi "fait-il mieux" que la page ?

Merci pour vos réponses !

[Isidore.76]

Quel comportement est-ce que tu voudrais avoir au fait ?

Bonne question

Dans un premier temps, ne pas afficher le contenu de la page d'erreur dans le div cible, c'est un minimum !

Ensuite, c'est assez délicat, il n'y a pas de réponse évidente ? Comment gérer l'erreur ?

Via javascript, afficher une boite de dialogue (alert) signalant l'erreur et recharger toute la page afin de l'afficher dans son état initial, puisque suite à l'erreur son "état" est "incohérent" ? Un peu à l'image d'une erreur pour une requête SQL dans le cadre d'une transaction : un "rollback", certes assez violent, pour revenir à l'état cohérent initial ?

Existe-t-il quelques bonnes pratiques sur le sujet ?

Je suis preneur de toute bonne idée

[Kaidan]

C'est à tester mais avant la redirection vers la page spécifiée dans la section customErrors du web.config, la page déclenche Error et l'application également. Si tu implémentes des gestionnaires pour traiter cet événement dans tes pages et/ou dans l'application, tu pourrais probablement traiter les erreurs liés à une exception non catchée tout en laissant les 404 etc. passer et être redirigées par le customErrors. Rien ne t'empêche à ce moment là de retourner un flux avec le code Javascript pour ouvrir une modale et afficher à l'utilisateur qu'il y a un soucis sans toucher le div.