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

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

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

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

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

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