J'essaye de déboguer du code en utilisant Response.Write, mais quand j'exécute le code, il saute cette instruction et les erreurs plus loin dans le code.Débogage avec Response.Write dans ASP classique
Comment puis-je afficher mes instructions Response.Write sans que les autres erreurs ne surviennent?
J'utilise fréquemment Response.End quand je dois voir un statut à un certain endroit sur une page.
Essayez un Response.Flush après vos instructions de débogage ou définissez Response.Buffer sur false.
Vous devrez utiliser l'instruction "on error resume next" en haut de votre page ASP. Cela résoudra votre problème quand une erreur survient, il passera à la ligne suivante plutôt que de lancer une erreur. Vous pouvez consulter ce lien http://www.powerasp.com/content/new/on-error-resume-next.asp pour référence.
Bonne programmation
Commentaire sur la ligne qui donne l'erreur et voir ce que l'respnse.write affiche est la seule chose raisonnable. N'utilisez pas on error resume next pendant que vous développez vos pages.
Vous devez vous assurer que vous construisez vos pages correctement et que vous produisez du code correct. Vous ne verrez aucune erreur si vous utilisez on error resume next. À mon avis, ne devrait être utilisé que dans les actions de base de données et dans le code livré (non développé). Dans ce cas, vous devez utiliser le
if Err.Number <> 0 then
construire pour tester toutes les erreurs. Vous ne pouvez tout simplement pas faire cela après chaque ligne dans asp si vous avez mis l'instruction on error resume next en haut de votre code, mais cela fait certainement du sens dans le code de gestion de base de données.
Nous utilisons Visual Studio 2008 pour déboguer les pages ASP classiques. Vous pouvez attacher au processus IIS et "parcourir" la page. C'est très doux. Voici les étapes:
Obtenez le dernier de l'ASP classique du contrôle de source.
Installez IIS (si ce n'est déjà fait). Pour info ... J'utilise IIS 5.1.
Créez un répertoire virtuel appelé "classicDebug" pointant vers votre répertoire local (C: \ Websites \ ClassicWebSite).
Affichez les propriétés du répertoire virtuel, onglet Répertoire virtuel.
Activez la case à cocher "Accès à la source du script".
Bouton de configuration, onglet Options - permet de tout vérifier.
Onglet Mise au point - vérifiez tout.
7a. Dans l'onglet ASP.NET, sélectionnez 2.x
Chargez (pas exécuter ou déboguer ou F5) dans le site Web VS.NET 2008.
Modifier votre global.asa en conséquence (sources de données, et les chemins). Trouvez la page .asp que vous voulez "parcourir" et définir un point d'arrêt en haut (ou quelque part).
Ouvrez IE et naviguez jusqu'à votre page.
Retour à VS.NET et sélectionnez Debug -> Attacher au processus
Cochez la case « Afficher les processus de tous les utilisateurs » et sélectionnez le processus. Pour moi (IIS 5.1), le nom du processus est dllhost.exe en cours d'exécution avec le compte IWAM_COMPUTERNAME avec le type "Script, T-SQL, Managed, x86".
Visitez votre page en utilisant IE ... VS.NET devrait casser.
merci pour l'étape par étape sur le faire avec vs 2008.J'utilise actuellement Visual Web Developer et ne permet pas d'attacher des processus – chobo
Ceci pourrait être une alternative à response.write.
J'ai mis en place cette classe d'inclusion ASP qui fonctionne avec Firebug + FirePHP. Il vous permet d'enregistrer des valeurs (y compris des chaînes, des tableaux multidimensionnels et même des objets créés avec json.asp) dans la console firebug et de voir les objets de collection intégrés d'ASP qui peuvent aider (en particulier avec Ajax). briser la réponse de JSON.) Les temps de chargement de script Ajax et les erreurs sont automatiquement enregistrés pour une visualisation rapide.
https://github.com/dmeagor/ClassicASP-FirePHP
comprennent uniquement le fichier journal et d'utilisation (somevalue) pour envoyer des variables formatées à la console Firebug.
Distribué sous la licence open source MIT
En parlant d'autres options, de poste David Meagor, vous pouvez également écrire des traces dans un fichier. Voici un exemple d'écriture de fichiers: http://www.4guysfromrolla.com/webtech/040699-1.shtml
Si vous le souhaitez, vous pouvez même placer les sous-programmes de suivi dans un fichier d'inclusion et l'utiliser dans toutes vos pages lorsque vous en avez besoin.
Une autre solution que nous utilisons est de mettre les méthodes de traçage dans un assembly .Net, enregistrez-le en COM puis appelez-le en utilisant CreateObject. Ces options vous permettront de conserver vos traces dans un fichier que vous pourrez consulter plus tard et partager avec d'autres développeurs.
Personnellement, j'utilise un mélange de ces approches: J'examine les fichiers journaux, j'utilise les points d'arrêt et je place même de temps en temps un Response.Write. Une autre chose: activer et consulter les journaux IIS: ils vous diront souvent sur quelle ligne votre page s'est cassée. Vous pouvez lire ici comment activer ou désactiver les journaux pour ASP classique: https://technet.microsoft.com/en-us/library/hh831387.aspx.
ne pas oublier de fermer ce bloc d'erreur avec un "sur erreur goto 0" à la fin –
Je ne pense pas que "sur erreur goto 0" fonctionne en ASP classique (du moins c'est ce que je vivais une fois.) – Edelcom
@Edelcom: "Sur erreur goto suivant" et "Sur erreur goto 0" sont les deux seules opérations "sur erreur" qui fonctionnent dans VBScript – AnthonyWJones