유용한 오류 메시지에 대한 개발자의 문제점은 무엇입니까? [닫은]

오늘날까지도 전문가 팀이 제작 한 벨트 아래에서 수년 동안 사용 된 제품은 오늘날 까지도 사용자에게 유용한 오류 메시지를 제공하지 못한다 는 사실은 계속해서 놀랍습니다 . 경우에 따라 약간의 추가 정보 만 추가하면 사용자의 문제를 해결할 수 있습니다.

오류를 발생시키는 프로그램으로 인해 오류가 발생했습니다. 가능한 한 많은 정보를 사용자에게 알리기 위해 모든 것을 갖추고 있습니다. 그러나 사용자를 돕기 위해 정보를 제공하는 것이 우선 순위가 낮은 것 같습니다. 나는 이것이 큰 실패라고 생각합니다.

한 예는 SQL Server입니다. 사용중인 데이터베이스를 복원하려고 시도하면 제대로 작동하지 않습니다. SQL Server 는 액세스하는 프로세스 및 응용 프로그램을 알고 있습니다. 데이터베이스를 사용하는 프로세스에 대한 정보를 포함 할 수없는 이유는 무엇입니까? 모든 사람이 Applicatio_Name연결 문자열에 속성을 전달하는 것은 아니지만 문제의 시스템에 대한 힌트조차 도움이 될 수 있습니다.

또 다른 후보자이며 SQL Server (및 mySQL)도 멋진 string or binary data would be truncated오류 메시지와 이에 상응하는 것입니다. 많은 시간, 생성 된 SQL 문에 대한 간단한 설명과 테이블은 범인이되는 열을 보여줍니다. 항상 그런 것은 아니며 데이터베이스 엔진이 오류를 발견하면 왜 그 시간을 절약 할 수없고 어떤 열이 손상되었는지 알려줄 수없는 이유는 무엇입니까? 이 예제에서는 성능을 검사하여 성능이 저하 될 수 있으며 이는 작성자를 방해 할 수 있다고 주장 할 수 있습니다. 좋아, 내가 살께 데이터베이스 엔진이 오류가 있음을 알게되면 저장 될 값과 열 길이를 비교하여 사후에 빠른 비교를 수행하는 방법은 무엇입니까? 그런 다음 사용자에게 표시하십시오.

ASP.NET의 끔찍한 테이블 어댑터도 유죄입니다. 쿼리가 실행될 수 있으며 어딘가에 제약 조건이 위반되었다는 오류 메시지가 표시 될 수 있습니다. 고마워 개발자가 행 번호 또는 예제 데이터를 제공하기에는 너무 게으 르기 때문에 데이터 모델과 데이터베이스를 비교할 시간입니다. (기록을 위해, 나는이 데이터 액세스 방법 을 선택 하여 사용하지 않을 것입니다. 이것은 내가 상속 한 프로젝트 일뿐입니다!).

C # 또는 C ++ 코드에서 예외를 처리 할 때마다 내가 가진 모든 것을 사용자에게 제공합니다. 그것을 던지기로 결정되었으므로 더 많은 정보를 줄수록 좋습니다. 왜 내 함수에서 예외가 발생 했습니까? 무엇이 전달되었고 무엇이 예상 되었습니까? 예외 메시지 본문에 의미있는 것을 넣는 데 시간이 조금 더 걸립니다. 내 코드가 의미있는 것을 던지기 때문에 내가 개발하는 동안 나 에게 도움이되지 않습니다 .

복잡한 예외 메시지가 사용자에게 표시되어서는 안된다고 주장 할 수 있습니다. 나는 그것에 동의하지 않지만, 그것은 당신의 빌드에 따라 다른 레벨의 자세한 정보를 가짐으로써 쉽게 이의를 제기 할 수있는 주장입니다. 그럼에도 불구하고 ASP.NET 및 SQL Server 사용자는 일반적인 사용자가 아니며 문제를 더 빨리 추적 할 수 있기 때문에 자세한 정보와 자세한 정보로 가득 찬 것을 선호합니다.

개발자들이 오늘날과 시대에 오류가 발생했을 때 최소한의 정보를 제공하는 것이 좋다고 생각하는 이유는 무엇입니까?

그것은 2011 남자의 올 에 .

잘못해서는 안되는 잘못된 오류 메시지의 예가 많이 있지만 항상보고 싶은 정보를 제공 할 수있는 것은 아니라는 점을 명심해야합니다.

너무 많은 정보를 노출하는 것에 대한 우려도 있으며, 이로 인해 개발자가주의를 기울여야 오류가 발생할 수 있습니다. (나는 말장난이 아니라고 약속하지만, 내가 그것을 알아 차린 지금 그것을 제거하지는 않는다.)

때로는 복잡한 오류 메시지가 최종 사용자에게 쓸모가 없다는 사실도 있습니다. 정보 과부하로 사이딩하는 것이 반드시 오류 메시지에 대한 좋은 접근 방식은 아닙니다. 로깅을 위해 저장하는 것이 가장 좋습니다.

개발자는 오류 메시지를 작성하는 데 적합하지 않습니다.

그들은 응용 프로그램을 잘못된 각도에서 본다. 그들은 코드 내부에서 무엇이 잘못되었는지 알고 있지만, 무언가를 달성하려는 관점에서 소프트웨어에 접근하지 않는 경우가 많습니다. 결과적으로 개발자에게 중요한 정보가 반드시 사용자에게 중요한 정보는 아닙니다.

자선보기 :

• 개발자는 코드와 긴밀히 협력하여 이해하지 못한 사람을 이해하기 위해 노력했습니다. 결과적으로 그들은 오류 메시지가 훌륭 하다고 생각하지만 , 그것들을 판단 할 수있는 좋은 참조 프레임이 없습니다.

• 지능형 오류 메시지는 실제로 수행하기가 어렵습니다. 글을 쓸뿐 아니라 잘못 될 수있는 모든 것을 해결하고, 가능성을 평가하고, 메시지를 읽는 사람에게 유용한 정보 (거의 상황에 따라 거의 다름)를 다시 제공하여 수정하도록합니다.

• 대부분의 응용 프로그램의 경우 오류가 자주 발생하지 않기 때문에 다음 개발자는 실제로 이런 종류의 작업을 수행하기에 좋은 사례를 만들기가 어렵습니다. 또한 여분의 시간이 있다면 오류를보고하는 대신 오류를 중지하는 데 소비해서는 안됩니까?

끝없는 견해 :

• 오류 메시지와 오류 처리가 지루하고, 작업해야 할 훨씬 더 흥미로운 것들이 있으며, 내 상사는 다음 일에 대해 내 뒤에 있습니다. 나는이 코드를 이해하고, 괜찮을 것이고, 다음 사람은 결국 그것을 해결할 것이고 그때까지 여기에서 나올 것이므로 내 문제가 아닙니다.

현실은 아마도 어딘가에 있지만, 내 경험에 따르면 실제로는 나중보다 훨씬 더 오래되었다고합니다. 기본적으로 실제로는 어려우며 아마 일어날 수없는 일을 처리하기 위해 상당한 노력이 필요합니다.

불행히도, 더 유용한 오류 메시지는 개발자 시간과 비용이 들며 이는 회사 돈과 같습니다. 제품은 그대로 구축하기에 충분히 비쌉니다. 예, 더 유용한 오류 메시지가 있으면 좋을 것입니다. 더 유용한 오류 메시지가 포함되어야한다는 데 동의합니다. 그러나 마감일에 처해 있고 돈이 줄을 섰을 때 무언가를 잘라야한다는 것은 인생의 사실입니다. 관리자가 볼 수 있듯이 "예쁜 오류 메시지"는 가장 먼저 갈 것입니다.

오류 메시지가 최대한 구체적이어야한다는 데 동의합니다.

일반적인 오류 메시지의 한 가지 이유는 아마도 오류 코드를 사용하는 것입니다. 예외를 사용할 때 오류 메시지에 필요한 모든 것을 자유롭게 전달할 수 있습니다. 리턴 코드를 사용하면 열 이름을 인코딩 할 공간이 없습니다. 아마도 오류는 컨텍스트를 모르고 단순히 오류 코드를 문자열로 변환하는 일반 함수에 의해 처리됩니다.

• 때로는 너무 많은 정보가 보안 위험이 될 수 있습니다. 누가 오류 메시지를 읽고 있는지 모른다
• 때로는 예외를 던진 작업이 너무 복잡하여 코드의 속도 / 복잡성에 부정적인 영향을 미치지 않으면 서 의미있는 메시지를 얻는 것이 불가능합니다.

일반적으로 모든 오류 또는 예외 상황은 정확히 다음과 같다는 점을 고려해야합니다. 계획되고 설계된 절차를 교차 절단합니다. 작동하려는 작업 방식과 호환되지 않습니다. 그렇지 않은 경우 오류 중단으로 구제 할 필요가 없습니다.

프로그래머는이 계획된 절차의 자체 보호를 관리하도록 훈련받습니다. 따라서 우리는 가정을 검증하기 위해 정기적으로 위생 검사를 포함합니다. 이러한 위생 검사가 실패하면 계획이 어떻게 든 실패한 것입니다 ...

이러한 시스템의 작동 방식을 고려할 경우 사용자 관점에서 상식처럼 보일 수있는 요구 사항을 충족 할 수 없습니다. 체계적이고 적절한 정보가 추가 된 질서있는 진술서를 요구합니다 . 또한이 프리젠 테이션을 일반적인 애플리케이션 / 핸들링 디자인에 적합한 방식으로 요청하기도합니다. 분명히이 정보는 시스템 어딘가에 존재합니다. 분명히 그것은 규칙적이고 체계적인 방식으로 존재하기도합니다 (희망하기를 바랍니다). 그러나 오류가 발생한 시점에서 아무도이 정보를 사용할 수 있도록 계획하지 않았습니다. 오류는 항상 부분적인 제어 손실입니다.이러한 통제력 상실은 다양한 수준에서 발생할 수 있습니다. 런타임시 계획된 것과 다르게 작동하는 시스템 일 수 있습니다. 그러나 실제 구현은 계획된 세부 사항에서 훨씬 더 어렵고 다른 것으로 나타 났으며, 이러한 상황을 만족스럽게 처리 할 수있는 규정이 없었습니다. 이것 역시 부분적인 통제력 상실입니다.

이것을 당신이 준 구체적인 예와 관련시키기 위해 : 오류가 발생했을 때 테이블 열의 이름과 유형을 알고 필요한 공간의 길이를 알면 아무런 이유가 없습니다. 오류가 발생하지 않습니까? 상황을 수정하고 계획대로 진행할 수 있습니다. 우리가 실수를해야만한다는 사실은 문제가 잘못되었다는 것을 보여줍니다. 이러한 정보가 제공되지 않는다는 사실 은 예외 입니다.

제가 여기서 쓰고있는 것은 자명하고 상식적인 것처럼 보일 수 있습니다. 그러나 실제로는 파악하기가 매우 어렵습니다. 우리는 도덕적 범주 를 적용하여 지속적으로 이해하려고 노력 합니다. 이 모든 것은 요점을 완전히 넘어

통제력 상실의 가능성은 계획적이고 질서 정연하게 일을하고 있다는 사실에서 비롯됩니다 .

소프트웨어 회사의 지원 엔지니어로 일하며 종종 새로운 오류 메시지가 나타납니다. 자주 개발팀에 문의 할 때 응용 프로그램 소스에서 메시지를 검색해야합니다.

사용자에게 제공되지 않았더라도 개발자 팀이 새 메시지를 추가 할 때마다 오류 메시지 색인 문서 또는 데이터베이스에 메모를 추가하면 많은 시간이 안전하다고 생각됩니다. 고객 문제의 원인을 찾고 시간을 절약 할 수있는 훨씬 빠른 속도 ...

당신이보고있는 문제는 실제로 적절한 캡슐화와 정보 숨기기의 부작용 중 하나입니다.

현대 시스템은 매우 복잡합니다. 일반 개발자가 특정 작업을 코딩하는 동안 UI에서 원시 바이너리까지 전체 시스템의 정신 모델을 머리 속에 담을 수있는 가능성은 거의 없습니다.

따라서 개발자가 앉아서 데이터베이스 파일을 복원하는 비트를 코딩하는 동안 그의 정신 모델은 데이터베이스 파일 복원 작업을 둘러싼 비트로 완전히 채워져 있습니다. 그는 파일을 읽고, 속성을 확인하고, 버전을 읽고, 기존 데이터를 백업하고, 병합 / 덮어 쓰기 전략을 선택하는 등의 작업을 수행해야합니다 (물론 추측합니다. UI를 고려하면 예외 처리기에 쓰는 오류 문자열에 있습니다. 다음과 같은 것 :

catch (IOException error)
{
//File is in use
throw new GenericExceptionParsedByTheUIThread("File is in use.");
}

이 예제에서 파일을 사용하고 있거나 DB의 다른 스레드를 사용하는 프로세스와 관련하여 도움이되는 유용한 정보는 프로그래밍 방식으로 완전히 범위를 벗어납니다. DB 파일을 다루는 수백 개의 클래스가있을 수 있습니다. 파일을 사용하여 파일 시스템에 액세스하고 실행중인 다른 프로세스 (이 프로세스가이 시스템에 있다고 가정)를 사용하여 다른 모든 프로세스에 대한 정보를 해당 클래스로 가져 오면 새는 추상화가 발생합니다 . 생산성에는 직접적인 비용이 있습니다.

이것이 오늘날 이런 종류의 오류가 지속될 수있는 방법입니다. 분명히, 그들은 모두 고정되어야한다. 그러나 많은 경우에 생각보다 많은 오버 헤드가 있습니다 (예를 들어,이 기능을 사용하려면 원격 시스템이이 데이터베이스 파일을 원격 시스템에서 사용 중인지 확인하기 위해 네트워크 연결 및 공유 열거를 통과해야 할 수도 있습니다) 이유) 그리고 비용은 사소하지 않습니다.

내가 가장 좋아하는 것은 Univac Fortran IV 컴파일러였습니다 (70 년대 후반). 비 숫자를 읽을 때 충실하게 발표했습니다.

의미없는 데이터의 해석이 시도되었습니다

나는 대부분의 오류 메시지가 실제로 프로그래머 (자체) 지향의 영광스러운 디버깅 코드 / printf 문이라고 생각합니다.

사용자 지향 오류 메시지를 작성한다는 것은 사용자가 누구인지 알고 자신이 알고 싶은 것을 예상한다는 것을 의미합니다. 코드를 작성하는 동안 개발자는 현재 작성중인 코드를 디버깅하거나 알려진 사용 또는 우세한 사용 사례에 유용한 오류 메시지를 작성하는 데 더 적합합니다.

코드 작성에서 사용자 인터페이스 (또는 사용자 경험)의 텍스트 부분 디자인으로 전환하는 것은 컨텍스트 전환입니다. 다국어 응용 프로그램과 같은 대규모 응용 프로그램에서는 개발자가 완전히 처리하지 않고 다른 사람이나 팀 (UI, 번역)에게 전달할 수 있으므로 개발자가 메시지의 내용을 신중하게 설명하지 않는 한 중요한 세부 정보가있을 수 있습니다. 쉽게 잃어 버렸습니다.

물론, 오류 및 예외가 처리 (즉, 포착)되는 한 오류 처리를 점검하고 확인하는 것이 우선 순위가 낮은 것으로 간주되는 경우가 많지만 강조하지는 않습니다. 오류 조건에 종종 부정적 의미 (예 : 실수 또는 실패)가 있기 때문에 개발자 또는 QA가 평가할 수있는 것은 코드베이스에서 정신적으로 보람이없는 장소입니다.

그 이유는 오류보고 / 처리가 항상 사후 생각으로 수행되기 때문 이라고 생각 합니다. 그들이 완전히 생각한 후에도, 그들은 전체 디자인에서 대부분 2 급 시민입니다.

최신 소프트웨어는 일반적으로 여러 계층으로 구성됩니다. 너무 많은 생각없이 오류보고 논리를 서두르면 유용한 오류 메시지를 표시하는 데 필요한 모든 정보 를 수집하기가 어려운 경우가 많습니다 .

예를 들어, 백엔드에서 오류가 발생하지만 종합적인 오류 메시지를 작성하려면 상위 계층의 일부 정보가 필요합니다. 가장 좋은 오류 메시지는 거의 모든 계층의 정보가 필요합니다 (시스템에서 발생한 상황에 대한 포괄적 인보기를 제공하기 위해). 이상적인 오류 메시지는 다음과 같습니다. "처음에 문자열을받은 다음 파서를 통과하여 재미있는 것을 제공했습니다. 여기를보고 싶을 수도 있습니다.

설계 단계에서 오류보고 메커니즘이 일류 시민이 아닌 경우 종종 불필요한 커플 링이 필요합니다. 나는 대부분의 사람들이 인상적이지 않은 무언가를 위해 너무 많은 일을한다고 생각한다. ( "누구? 내 프로그램이 추락하고 오류 메시지가 유용하다!"