asp または asp.net のどちらでも、response.end は出力コンテンツを終了し、特にプログラムに無限ループなどの重大な問題がある場合に、ブレークポイントの設定と同様にプログラムのデバッグに非常に役立ちます。 write では中間結果を確認できません。この場合、response.write の後にresponse.end を追加すると、中間結果を確認するのに非常に便利です。
まずはそのメリットについてお話しましょう。
これは、プログラムをデバッグする場合にも非常に役立ちます。たとえば、プログラムに重大な問題がある場合、response.write を使用しても中間結果を確認できません。 、response.write の後に、response.end を追加します。これは、中間結果を表示するのに役立ちます。
ただし、Response.End、Response.Redirect、または Server.Transfer メソッドを使用すると、ThreadAbortException が発生します。この例外は、try-catch ステートメントを使用してキャッチできます。
Response.End メソッドはページの実行を終了し、アプリケーションのイベント パイプラインの Application_EndRequest イベントに実行を切り替えます。 Response.End に続くコード行は実行されません。
この問題は、Response.Redirect メソッドと Server.Transfer メソッドで両方のメソッドが内部で Response.End を呼び出すために発生します。
解決：
この問題を解決するには、次のいずれかの方法を使用します。
• Response.End の場合、Response.End の代わりに HttpContext.Current.ApplicationInstance.CompleteRequest メソッドを呼び出して、Application_EndRequest イベントのコード実行をスキップします。
• Response.Redirect の場合は、オーバーロード Response.Redirect(String url, bool endResponse) を使用します。これは、endResponse パラメータに false を渡して、Response.End への内部呼び出しをキャンセルします。例えば：
Response.Redirect (Default.aspx、false);
Response.End() の使用法
ASP 開発では、if...else 判定の大きなセクションを使用することがありますが、それが動的な Response.write コンテンツであり、コードを読みやすくしたい場合は、Response.End() を使用できます。 ASP の実行を終了します。これは、次のような Break の使用法に似ています。
if (userid=)or(password=) then Response.Write() Response.End() 'ここで割り込み終了 if 次は、データベースが空でない場合に、n 行のコードを省略してデータベースを読み取る操作です。
このようにして、受信したユーザー名またはパスワードが空の場合、プロンプト情報が自動的に書き込まれ、Response.End() がプログラムを中断して if に到達します。 。 。他の人の役割。
また、Response.End を使用する場合は、次のようにプログラムを毎日デバッグするときです。
次のコードを実行せずに、結合された SQL ステートメントを出力するには、次のようにします。
sql=select * from userinfo response.Write(sql)response.End()rs.open sql ,conn,1,1 'この文は実行されません
Response.End() を追加する場所が多すぎて、正式リリース時にコメントアウトするのが難しい場合は、次のコードのような関数でカプセル化できます。
sub debug() Response.End()end sub
上記のコードは次のように変更されます。
sql=select * from userinfo response.Write(sql)debug()rs.open sql ,conn,1,1 'この文は実行されません
このように、正式リリース時には関数 debug 内の文をコメントアウトすることでデバッグの役割を果たすことができますが、これにも問題があり、あまりにも debug() を使いすぎるとプログラムが実行できなくなる可能性があります。デバッグ中に指示に従ってください。場合によっては、これらの場所で実行を中断したくない場合があるため、次のように debug() 関数を再構築してみましょう。
sub debug(isBreak) 'isBreak はブール値を持つパラメータです。true に設定されている場合、isBreak then Response.End() endend sub は割り込み処理を実行しません。
使用時のコードは次のとおりです。
sql=select * from userinfo response.Write(sql)debug(false)rs.open sql ,conn,1,1 'この文が実行されます rs.close()sql=select * from product response.write(sql) debug (true)rs.open sql,conn,1,1 'この文は実行されません
これは基本的に割り込み制御のニーズを満たすことができますが、実際にはまだ非常に不完全であり、さらに多くのデバッグ要件を満たす必要がある可能性があります。実際、プログラム開発はリファクタリング、リファクタリング、リファクタリングのプロセスです。そうでなければ、非常に多くの設計パターンが存在することになります。これらはすべて、先人たちが実際の開発とリファクタリングのプロセスから得た経験をまとめたものであり、学ぶ価値があります。