Использование Response.End() в asp

При разработке ASP иногда можно использовать большие разделы суждений if...else. Однако, если это динамический контент Response.write и вы хотите облегчить чтение кода, вы можете использовать Response.End() для этого. прекратить выполнение ASP. Это похоже на использование Break.

При разработке ASP иногда можно использовать большие разделы суждений if...else. Однако, если это динамический контент Response.write и вы хотите облегчить чтение кода, вы можете использовать Response.End() для этого. прекратить выполнение ASP. Это похоже на использование Break, например:

если (userid=)или(пароль=), то

Response.Write(<script lanuage=javascript>alert('Имя пользователя или пароль пусто!');location.href='../default.asp';</script>)

Response.End() 'Конец if прерывается здесь. Ниже приведена операция чтения базы данных, если она не пуста, без n строк кода.

Таким образом, если входящее имя пользователя или пароль пусты, информация подсказки записывается автоматически, а затем Response.End() прерывает программу, чтобы достичь if. . . Роль другого.

Кроме того, при использовании Response.End мы ежедневно отлаживаем программу, например

Чтобы вывести объединенный оператор SQL без выполнения следующего кода, вы можете сделать это

sql=выбрать * из информации о пользователе

ответ.Запись(sql)

ответ.Конец()

rs.open sql ,conn,1,1 'Это предложение не будет выполнено

Если вы боитесь, что места для добавления Response.End() будет слишком много и его будет сложно закомментировать, когда он будет официально выпущен, вы можете инкапсулировать его с помощью функции, например следующего кода:

суботладка()

Ответ.Конец()

конец субтитра

Приведенный выше код изменяется следующим образом:

sql=выбрать * из информации о пользователе

ответ.Запись(sql)

отлаживать()

rs.open sql ,conn,1,1 'Это предложение не будет выполнено

Таким образом, когда он официально выпущен, комментирование операторов в функции отладки может играть роль отладки. Однако с этим также есть проблема. Если вы используете слишком много debug(), программа может оказаться неспособной это сделать. следуйте инструкциям во время отладки. Иногда вам не хочется, чтобы выполнение прерывалось в этих местах, поэтому давайте реконструируем функцию debug() следующим образом:

sub debug(isBreak) 'isBreak — это параметр с логическим значением. Если для него установлено значение true, обработка прерывания не будет выполняться, если isBreak, то Response.End() endend sub.

Код при использовании выглядит следующим образом:

sql=выбрать * из информации о пользователе

ответ.Запись(sql)

отладка (ложь)

rs.open sql,conn,1,1 'Это предложение будет выполнено rs.close()

sql=выбрать * из продукта

ответ.запись (sql)

отладка (правда)

rs.open sql,conn,1,1 'Это предложение не будет выполнено

Хорошо, это в принципе может удовлетворить нашу потребность в управлении прерываниями, но это всего лишь простой анализ. На самом деле он все еще очень несовершенен. Возможно, потребуется выполнить еще много требований по отладке, и потребуется дальнейшая реконструкция. На самом деле разработка программы — это процесс рефакторинга, рефакторинга и рефакторинга. В противном случае существовало бы очень много шаблонов проектирования. Это все опыт, накопленный предшественниками в реальном процессе разработки и рефакторинга, и им стоит поучиться.