Que ce soit dans asp ou asp.net, response.end termine le contenu de sortie et est principalement utilisé pour le débogage des programmes. Il est également très utile, similaire à la définition de points d'arrêt, en particulier lorsque votre programme rencontre des problèmes majeurs, comme une boucle infinie. write ne peut pas voir les résultats intermédiaires. Dans ce cas, ajoutez Response.end après Response.write Ceci est très utile pour afficher les résultats intermédiaires.
Parlons d’abord de ses avantages.
C'est également très utile lors du débogage d'un programme. C'est similaire à la définition de points d'arrêt, surtout si votre programme a des problèmes majeurs. Par exemple, lorsqu'il y a une boucle infinie, les résultats intermédiaires ne peuvent pas être vus en utilisant Response.write. , après Response.write Ajoutez Response.end, ce qui est utile pour afficher les résultats intermédiaires.
Toutefois, si vous utilisez la méthode Response.End, Response.Redirect ou Server.Transfer, une ThreadAbortException se produira. Vous pouvez intercepter cette exception à l'aide d'une instruction try-catch.
La méthode Response.End termine l'exécution de la page et bascule l'exécution vers l'événement Application_EndRequest dans le pipeline d'événements de l'application. Les lignes de code qui suivent Response.End ne sont pas exécutées.
Ce problème se produit dans les méthodes Response.Redirect et Server.Transfer, car les deux méthodes appellent Response.End en interne.
Solution:
Pour résoudre ce problème, utilisez l'une des méthodes suivantes :
• Pour Response.End, appelez la méthode HttpContext.Current.ApplicationInstance.CompleteRequest au lieu de Response.End pour ignorer l'exécution du code pour l'événement Application_EndRequest.
• Pour Response.Redirect, utilisez la surcharge Response.Redirect(String url, bool endResponse), qui transmet false pour le paramètre endResponse afin d'annuler l'appel interne à Response.End. Par exemple:
Response.Redirect (Default.aspx, faux);
Utilisation de Response.End()
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 :
if (userid=)or(password=) then Response.Write() Response.End() 'Voici la fin de l'interruption if 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
sql=select * from userinfo response.Write(sql)response.End()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 :
sub debug() Response.End()end sub
Le code ci-dessus est modifié comme suit :
sql=select * from userinfo response.Write(sql)debug()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 puis Response.End() endend sub.
Le code lorsqu'il est utilisé est le suivant :
sql=select * from userinfo response.Write(sql)debug(false)rs.open sql ,conn,1,1 'Cette phrase sera exécutée rs.close()sql=select * from product response.write(sql) debug (true)rs.open sql,conn,1,1 'Cette phrase ne sera pas exécutée
D'accord, cela peut essentiellement répondre à nos besoins de contrôle des interruptions. Cependant, 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.