ASP 개발에서는 if...else 판단의 큰 섹션을 사용할 수도 있습니다. 그러나 동적 Response.write 콘텐츠이고 코드를 더 쉽게 읽을 수 있도록 하려면 Response.End()를 사용하면 됩니다. ASP 실행을 종료합니다. Break의 사용법과 유사합니다.
ASP 개발에서는 if...else 판단의 큰 섹션을 사용할 수도 있습니다. 그러나 동적 Response.write 콘텐츠이고 코드를 더 쉽게 읽을 수 있도록 하려면 Response.End()를 사용하면 됩니다. ASP 실행을 종료합니다. 이는 Break의 사용법과 유사합니다. 예를 들면 다음과 같습니다.
다음과 같이 코드 코드를 복사합니다.if (사용자 ID=)또는(비밀번호=) then
Response.Write(<script lanuage=javascript>alert('사용자 이름 또는 비밀번호가 비어 있습니다!');location.href='../default.asp';</script>)
Response.End() '여기서 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()를 너무 많이 사용하면 프로그램이 실행되지 못하는 경우가 있습니다. 디버깅하는 동안 지침을 따르십시오. 때로는 이러한 위치에서 실행이 중단되는 것을 원하지 않으므로 다음과 같이 debug() 함수를 다시 구성해 보겠습니다.
sub debug(isBreak) 'isBreak는 부울 값을 갖는 매개변수입니다. true로 설정되면 인터럽트가 수행됩니다. 그렇지 않으면 isBreak이면 Response.End() endend sub가 수행됩니다.
사용시 코드는 다음과 같습니다.
다음과 같이 코드 코드를 복사합니다.sql=사용자 정보에서 * 선택
응답.쓰기(sql)
디버그(거짓)
rs.open sql,conn,1,1 '이 문장이 실행될 것입니다 rs.close()
sql=제품에서 * 선택
response.write(sql)
디버그(사실)
rs.open sql,conn,1,1 '이 문장은 실행되지 않습니다.
좋습니다. 이는 기본적으로 인터럽트를 제어해야 하는 요구 사항을 충족할 수 있지만 이는 단순한 분석에 불과하며 충족해야 할 디버깅 요구 사항이 더 많이 있을 수 있으며 추가 재구성이 필요합니다. 사실 프로그램 개발은 리팩토링, 리팩토링, 리팩토링의 과정입니다. 그렇지 않으면 디자인 패턴이 너무 많을 것입니다. 모두 실제 개발 및 리팩토링 과정에서 선배들이 요약한 경험이며 배울 가치가 있습니다.