Dans le développement ASP, vous pouvez parfois utiliser de grandes sections de jugements if...else. Cependant, s'il s'agit d'un contenu Response.write dynamique et que vous souhaitez faciliter la lecture du code, vous pouvez utiliser Response.End() pour le faire. mettre fin à l’exécution d’ASP C’est similaire à l’utilisation de Break.
Dans le développement ASP, vous pouvez parfois utiliser de grandes sections de jugements if...else. Cependant, s'il s'agit d'un contenu Response.write dynamique et que vous souhaitez faciliter la lecture du code, vous pouvez utiliser Response.End() pour le faire. terminer l'exécution d'ASP C'est similaire à l'utilisation de Break, par exemple :
Copiez le code comme suit :si (IDutilisateur=)ou(mot de passe=) alors
Response.Write(<script lanuage=javascript>alert('Le nom d'utilisateur ou le mot de passe est vide !');location.href='../default.asp';</script>)
Response.End() 'La fin du if est interrompue ici. Ce qui suit est l'opération de lecture de la base de données si elle n'est pas vide, en omettant n lignes de code.
De cette façon, lorsque le nom d'utilisateur ou le mot de passe entrant est vide, les informations d'invite sont automatiquement écrites, puis Response.End() interrompt le programme pour atteindre le if. . . Le rôle d'autre.
De plus, lorsque nous utilisons Response.End, c'est lorsque nous débogueons quotidiennement le programme, comme
Pour générer l'instruction SQL épissée sans exécuter le code suivant, vous pouvez le faire
Copiez le code comme suit :sql=select * à partir des informations utilisateur
réponse.Write(sql)
réponse.Fin()
rs.open sql ,conn,1,1 'Cette phrase ne sera pas exécutée
Si vous craignez qu'il y ait trop d'endroits pour ajouter Response.End() et qu'il ne sera pas facile de commenter lors de sa sortie officielle, vous pouvez l'encapsuler avec une fonction, comme le code suivant :
Copiez le code comme suit :sous-débug()
Réponse.Fin()
fin du sous
Le code ci-dessus est modifié comme suit :
Copiez le code comme suit :sql=select * à partir des informations utilisateur
réponse.Write(sql)
déboguer()
rs.open sql ,conn,1,1 'Cette phrase ne sera pas exécutée
De cette façon, lors de sa sortie officielle, commenter les instructions dans la fonction debug peut jouer un rôle de débogage. Cependant, cela pose également un problème si vous utilisez trop de debug(), le programme risque de ne pas pouvoir le faire. suivez les instructions pendant le débogage. Des interruptions sont nécessaires. Parfois, vous ne souhaitez pas que l'exécution soit interrompue à ces endroits, reconstruisons donc davantage la fonction debug(), comme suit :
sub debug(isBreak) 'isBreak est un paramètre avec une valeur booléenne. S'il est défini sur true, il interrompra. Sinon, aucun traitement d'interruption ne sera effectué si isBreak alors Response.End() endend sub.
Le code lorsqu'il est utilisé est le suivant :
Copiez le code comme suit :sql=select * à partir des informations utilisateur
réponse.Write(sql)
déboguer (faux)
rs.open sql,conn,1,1 'Cette phrase sera exécutée rs.close()
sql=sélectionner * à partir du produit
réponse.write(sql)
déboguer (vrai)
rs.open sql,conn,1,1 'Cette phrase ne sera pas exécutée
D'accord, cela peut essentiellement répondre à notre besoin de contrôler les interruptions, mais ce n'est qu'une simple analyse, en fait, elle est encore très imparfaite. Il peut y avoir beaucoup plus d'exigences de débogage à satisfaire et une reconstruction supplémentaire est nécessaire. En fait, le développement d'un programme est un processus de refactorisation, de refactorisation et de refactorisation, sinon il y aurait tellement de modèles de conception. Ce sont toutes les expériences résumées par les prédécesseurs du processus de développement et de refactorisation réel, et elles méritent d'être apprises.