알고스팟 온라인 저지에서는 정답이 아닌 답안에 대해, "시간초과", "런타임 오류", "오답" 등의 결과를 제외하고는 구체적인 오답 사유를 공개하지 않는 것을 원칙으로 하고 있습니다. 공개하지 않는 것들은 다음과 같습니다:

1. 입출력 테스트 케이스
2. 표준 에러 파일로(stderr) 출력된 각종 정보
   • 이는 언어들의 예외 처리 메커니즘을 포함합니다.
   • 따라서 스택 트레이스나 예외 메세지 등도 제공되지 않습니다.

한편, 컴파일 에러의 경우 입출력과 무관한 것이므로 어디서 발생한 것인지 알려주고 있습니다.

이러한 원칙이 적용되게 된 데에는 다음과 같은 이유가 있습니다:

1. 입출력 테스트 케이스 유출 방지
   • 알고스팟의, 특히 대다수를 차지하는 자체적으로 제작한 문제들의 경우 여기에서만 채점 가능한 것을 목표로 하고 있습니다.
2. 오답 테스트 케이스를 특정하는 것의 어려움
   • 입력과 출력 형식이 문제마다 서로 다르고, 탑코더와 같은 표준화된 인터페이스를 사용하는 것이 아니기 때문에 어떤 테스트 케이스가 틀렸다는 것을 제공하기 어렵습니다.
   • 한 번의 테스트에서 여러 개의 테스트 케이스를 제공하는 대신, 한 번당 하나의 테스트 케이스를 제공하는 것으로 대신할 수도 있겠으나, 다음과 같은 이슈가 있습니다:
     • 기존 문제들을 모두 변환하는 데에는 상당히 큰 운영진의 노동이 필요합니다.
     • PC^2와 같은 컨테스트 운영에 사용되는 플랫폼에서 여러 개의 입력 파일을 채점하는 것이 상당히 어렵습니다. 과거 모의 대회나 전국 대학생 프로그래밍 대회 연합 경진대회 등의 사례를 보면, 아직까지도 다른 대안이 뚜렷하지 않은 상황이어서 기존 플랫폼을 사용하는 경우가 많습니다. 따라서 이렇게 대회를 진행하게 되면 대회의 채점 기준과 온라인 저지의 채점 기준이 크게 달라지는 문제가 생깁니다.
     • 채점 결과를 무엇을 기준으로 제공해야 좋은지 애매해지게 됩니다.
     • Java와 같이 한 번 프로세스를 띄우고 내리는 데 오버헤드가 큰 언어의 경우, 수행 시간 측정에 더더욱 큰 어려움을 겪게 됩니다.
3. 학습 효율성과의 상관관계에 대한 의문
   • 숙련된 학습자의 경우 테스트케이스를 제공하는 것만으로 자신의 알고리즘/로직이 잘못되는 것을 쉽게 파악할 수 있습니다만, 입문자들의 경우 특정 테스트 케이스가 '예외'라고 생각하고 자신의 로직이 뼈대부터 잘못 설계되었다는 생각을 하지 못하는 경향이 있습니다.
   • 또한 대부분의 테스트 케이스들은 아주 큰 입력이므로, 값을 제공하더라도 무엇이 잘못되었는지 찾아내기는 쉽지 않습니다.
   • 따라서 이런 경우 질문과 답변 게시판을 활용하여 조언을 구하는 것을 운영 방침으로 하고 있습니다.

이 원칙은 어디까지나 '현상'에 대한 것이고, 충분한 논의가 이루어지면 변경될 수 있습니다.