응용 프로그램은 항상 오류를 발생시킬 수 있습니다. 이러한 오류가 발생하면 응용 프로그램에 요청한 작업이 성공하지 못했기 때문에 사용자에게 알려야합니다.
그러나 사용자에게 얼마나 많은 정보를 제공해야합니까? 대부분의 사람들이 스택 추적을 표시하지 않는 데 동의한다고 생각합니다 ( 스택 추적이 사용자에게 제시된 오류 메시지에 있어야합니까? ), 나머지 오류 내용 또는 표시 할 내용에 대한 질문을 찾을 수 없습니다 사용자.
예를 들어, 예외를 지원하는 언어 (.net, java)는 예외 유형이 공유되며 예외가 발생한 위치와 예외와 함께 진행해야 할 메시지가 명확합니다. 사용자에게도 숨겨져 야합니까? 아니면 어쨌든 이것을 보여줘야합니까? 아니면 일반적인 메시지를 보여 주어야합니까? 또는 기본 예외가 무엇인지에 따라 여러 메시지 중 하나를 표시해야합니까?
답변:
사용자에게 보여줄 것. 사용자에게도 숨겨져 야합니까?
사용자에게 실행 가능한 것을 보여줍니다.
예를 들어, 널 포인터 예외 및 사용자 오류보다 버그로 인해 오류가 발생하면 다른 작업을 수행 할 수 없기 때문에 자세한 설명을 원하지 않습니다.
아니면 어쨌든 이것을 보여줘야합니까? 아니면 일반적인 메시지를 보여 주어야합니까?
대부분의 사용자에게 예외를 주요 오류 메시지 내용으로 표시하는 것은 의미가 없습니다 . 대상 사용자 기반이 개발자 인 경우 정보를 항상 전체 오류로 표시 할 수 있습니다 (자동 테스트를위한 내부 애플리케이션이있을 수 있음). 그러나 일반적으로 사용자는 그 지식으로도 다른 것을 할 수 없습니다.
기본 예외가 무엇인지에 따라 여러 메시지 중 하나를 표시해야합니까?
최선의 전략은 다음을 수행하는 것입니다.
경우에 따라 오류 보고서를 수동 대 자동으로 만들 수도 있습니다.
You show the user what is actionable for them. 문제점의 원인을 알고 있으면 설명에서이를 사용자에게 표시하십시오. 그러나 일반적으로 오류 이유를 알고 있으면 사용자에게 적절하게 알리기위한 문제 해결 방법을 알게 됩니다.
사용자가 누구이며 정보로 무엇을 할 수 있는지에 달려 있습니다.
일반적으로, 스스로 해결할 수있는 것에 대한 유용한 정보 만 보여주십시오. 맨 위에 정규식 오류가있는 40 행 스택 추적은 그다지 유용하지 않습니다. Date가 "yyyy-mm-dd"형식이어야 한다는 메시지가 훨씬 좋습니다 . 다른 어떤 것도 사용자는 오류에 응답하는 방법을 알지 못하고 응용 프로그램을 사용하고 싶지 않을 수 있습니다. 흔적). 그리고 그것은 사업에 좋지 않을 수 있습니다.
다른 개발자가 사용하는 내부 응용 프로그램의 경우 사용자가 스택 추적을 볼 수 있고 스택 추적을 수행하는 방법을 알 수 있기 때문에 더 유용한 것 외에도 스택 추적을 표시하는 데 약간 더 편합니다 .
기술이 아닌 사용자의 경우 스택 추적을 보여줄 수 있다고 생각하는 유일한 시간 은 문제를 해결하기 위해 필요한 중대한 오류 상황에 있으며 스택 추적을 복사하여 붙여 넣어 보내라는 메시지가 나타납니다. 실제로는 훨씬 더 좋은 방법은 로그 파일을 보내도록 요청하는 것입니다. 더 나은 방법은 파일 공유 권한을 사용자에게 요청한 후 응용 프로그램이 개발자에게 로그 파일을 보내도록하는 것입니다.
사용자에게 보내는 메시지는 새 예외를 생성하는 것과 같은 방식으로 처리해야합니다. 사용자는 수행 할 작업을 결정하는 데 필요한 정보를 제공합니다.
물론 이것은 응용 프로그램과 사용자 기반에 따라 다르지만 기본 원칙이어야합니다. "호출자"가 원하는 조치를 수행하기 위해 무엇을 할 수 있는지 결정하기 위해 필요한 정보를 제공해야합니다. . 파일에 대한 액세스 오류와 같이 단순한 경우 파일 경로와 파일에 액세스 할 수 없다는 메시지를 제공합니다. 널 포인터 예외 인 경우 일반적인 오류 메시지를 제공하십시오.
물론 사용자가 실제로 고칠 수있는 것보다 "원하는 조치를 수행 할 수 없습니다"메시지가 더 많이있을 것입니다. 그러나 그것은 단지 인생입니다. 대부분의 예외는 사용자가 환경을 설정했기 때문이 아니라 실수를했기 때문입니다. 틀리게.
나는 받아 들여진 대답에 대한 이론적 근거를 좋아하지만 적어도 정보를 "실행 가능한" 것으로 제한한다는 나의 해석에 대해 정중하게 동의하지 않아야한다 . "예기치 않은 오류" 보다 사용자보다 조금 더 작은 것을 알고 싶습니다 .
그리고 분명히 컴퓨터에 정통하고 편견이 있지만 이것이 특히 편견이라고 생각하지 않습니다. 항공과 같은 전문 지식이 거의없는 도메인에이 사고 방식을 적용하여 이러한 편견을 제거하기 위해 최선을 다할 수 있기 때문입니다.
항공에 대해 거의 알지 못하지만 비행이 지연되거나 취소되었다고 직원이 말한 유일한 것은 "예기치 않은 오류가 발생했습니다. 후속 비행을 위해 3 시간 정도 기다려주십시오." 실제로 어떤 경우에도 제 행동에 영향을 미치지는 않지만, 왜 내가 왜 있는지에 대해 조금 더 알고 싶기 때문에 불만이있는 고객을 적어도 조금 더 알게 될 것입니다. 유료 고객으로서 이러한 방식으로 불편을 겪었습니다.
그들이 "우리는 혹독한 날씨를 겪고있다"또는 "이전 비행에서 의학적 응급 상황이 발생했거나"장비 오작동 또는 그와 같은 말을한다면, "예기치 않은 오류"보다 훨씬 더 공감할만큼 충분합니다. 다음 비행을 위해 앉아서 3 시간을 기다리는 더 많은 콘텐츠가 있어야합니다. 사실, 나는 "예기치 않은 오류"로 머리 위로 넘어가는 기술 노바 블을 선호 할지도 모른다. 거기에 문제가 생겼고 커피를 마시고 거기에 앉아있을 것입니다!
그리고 종종 예외 처리 측면에서 catch, 다음과 같이 예외에 대한 더 자세한 기술 정보를 숨기고 싶더라도 사이트 에서 일어난 일에 대한 기본 정보가 충분하다고 생각합니다 .
try
{
load_file(file_name);
}
catch (const exception& ex)
{
exception_dialog("Failed to load file: '{1}'.", file_name);
}
그리고 그것은 예외에 첨부 된 매우 기술적 인 정보가 될 수있는 것을 보여주지는 않지만 최소한 "예기치 않은 오류"이상을 말해줍니다. 그것은 "왜 / 어떻게"라고 말하지 않더라도 적어도 문맥 상 "무엇 / 어디 / 어디"를 제공합니다. 최소한이 기본 정보 수준에 대한 열망은 특히 컴퓨터 절약에 의해 편향되지 않는다고 생각합니다.
나머지는 아마도 고객 및 특정 요구에 따라 매우 다를 수 있습니다. 그러나 나의 호소는 적어도 "예기치 않은 오류"보다 조금 더 작은 것에 대한 것이다.