처리되지 않은 예외를 처리하는 방법? (응용 프로그램 종료 및 유지)


30

데스크톱 응용 프로그램에서 처리되지 않은 예외가 발생할 때 가장 좋은 방법은 무엇입니까?

고객에게 지원을 요청할 수 있도록 메시지를 표시하려고했습니다. 사용자에게 응용 프로그램을 다시 시작하는 것이 좋지만 강제로 실행하지 않는 것이 좋습니다. ux.stackexchange.com에서 논의 된 것과 유사 -예상치 못한 애플리케이션 오류를 처리하는 가장 좋은 방법은 무엇입니까?

이 프로젝트는 .NET WPF 응용 프로그램이므로 설명 된 제안은 다음과 같습니다 (이는 간단한 예입니다. 사용자가 "세부 정보 표시"를 클릭하고 일부 기능을 제공 할 때까지 예외 세부 정보를 숨기는 것이 좋습니다. 쉽게 오류를보고하십시오) :

public partial class App : Application
{
    public App()
    {
        DispatcherUnhandledException += OnDispatcherUnhandledException;
    }

    private void OnDispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e)
    {
        LogError(e.Exception);
        MessageBoxResult result = MessageBox.Show(
             $"Please help us fix it and contact support@example.com. Exception details: {e.Exception}" +
                        "We recommend to restart the application. " +
                        "Do you want to stop the application now? (Warning: Unsaved data gets lost).", 
            "Unexpected error occured.", MessageBoxButton.YesNo);

        // Setting 'Handled' to 'true' will prevent the application from terminating.
        e.Handled = result == MessageBoxResult.No;
    }

    private void LogError(Exception ex)
    {
        // Log to a log file...
    }
}

구현 (ViewModels 명령 또는 외부 이벤트의 이벤트 처리기)에서 특정 외생 적 예외 만 포착하고 다른 모든 예외 (boneheaded 및 unknown 예외)가 위에서 설명한 "마지막 리조트 핸들러"로 버블 링되도록합니다. 본 헤드 및 외인성 예외에 대한 정의는 다음을 참조하십시오. Eric Lippert-Vexing 예외

사용자가 응용 프로그램을 종료해야하는지 결정하도록하는 것이 합리적입니까? 응용 프로그램이 종료되면 일관성이없는 상태가 아니어야합니다 ... 반면에 사용자는 저장하지 않은 데이터를 잃어 버리거나 응용 프로그램을 다시 시작할 때까지 더 이상 시작된 외부 프로세스를 중지 할 수 없습니다.

또는 작성중인 응용 프로그램 유형에 따라 처리되지 않은 예외에 대해 응용 프로그램을 종료해야하는지 여부가 결정입니까? Code Complete, Second Edition에 설명 된 것처럼 "견고성"과 "정확성"간의 절충점 일 뿐입니 까?

우리가 어떤 종류의 응용 분야에 대해 이야기하고 있는지 알려면 :이 응용 프로그램은 주로 화학 실험실 장비를 제어하고 측정 결과를 사용자에게 보여주기 위해 사용됩니다. 그렇게하기 위해 WPF 응용 프로그램은 일부 서비스 (로컬 및 원격 서비스)와 통신합니다. WPF 응용 프로그램은 계측기와 직접 통신하지 않습니다.


27
예외가 예상되지 않은 경우 애플리케이션이 플로팅을 안전하게 유지할 수있는 방법을 어떻게 알 수 있습니까?
중복 제거기

2
@ 중복 제거기 : 물론, 당신은 확신 할 수 없습니다. Matthew의 답변에 대한 주석으로 이미 작성된 것처럼 "예, 물론 응용 프로그램이 잘못된 상태 일 수 있습니다. 일부 ViewModel이 부분적으로 만 업데이트되었을 수 있습니다. 그러나 이로 인해 피해를 입을 수 있습니까? 서비스로 전송하면 서비스가 서비스를 수락하지 않습니다. 응용 프로그램을 다시 시작하기 전에 저장할 수 있으면 사용자에게 더 좋지 않습니까? "
조나스 벤츠

2
@Voo 따라서 항상 예외를 기대하여 응용 프로그램이 안전하게 계속 진행될 수 있도록 하시겠습니까? 예기치 않은 예외가 발생한다는 전제를 거부하고있는 것 같습니다.
중복 제거기

2
어쨌든 오류 메시지를 복사 가능하게 만드십시오. 또는 어떤 로그 파일에 작성했는지 말하십시오.
ComFreek

2
취급이 반드시 명시적인 행동을 의미하지는 않습니다. 응용 프로그램이 안전하게 계속 진행될 수 있다고 확신하면 예외를 처리 한 것입니다.
chepner

답변:


47

어쨌든 정전 또는 전체 시스템과 충돌하는 다른 백그라운드 프로세스와 같이 처리되지 않은 예외보다 더 많은 이유로 프로그램이 종료 될 것으로 예상해야합니다. 그러므로 나는 종료하고 응용 프로그램을 다시 시작하는 것이 좋습니다,하지만 몇 가지 조치하는 등 다시 시작의 결과를 완화 하고 가능한 데이터 손실을 최소화 .

다음 사항을 분석하여 시작하십시오.

  • 프로그램 종료시 실제로 얼마나 많은 데이터가 손실 될 수 있습니까?

  • 사용자에게 그러한 손실이 얼마나 심각합니까? 잃어버린 데이터를 5 분 이내에 재구성 할 수 있습니까, 아니면 하루 일을 잃는 것에 대해 이야기하고 있습니까?

  • "중간 백업"전략을 구현하는 데 얼마나 많은 노력이 필요합니까? 주석에 기록한대로 정기적 인 저장 조작에서 "사용자가 변경 이유를 입력해야하기 때문에 " 이를 배제하지 마십시오 . 프로그램이 자동으로 중단 된 후 다시로드 될 수있는 임시 파일 또는 상태와 같은 것을 더 잘 생각하십시오. 많은 유형의 생산성 소프트웨어가이를 수행합니다 (예 : MS Office 및 LibreOffice 모두 "자동 저장"기능 및 응급 복구 기능이 있음).

  • 데이터가 잘못되었거나 손상된 경우 사용자가이를 쉽게 볼 수 있습니까 (프로그램을 다시 시작한 후)? 그렇다면, 사용자가 데이터를 저장하고 (약간 손상되었을 가능성이있는) 옵션을 제공 한 후 강제로 다시 시작하고 다시로드하여 사용자에게 데이터가 제대로 표시되는지 확인할 수 있습니다. 이전 버전이 손상되지 않도록 정기적으로 저장된 마지막 버전 (임시 위치 / 파일에 쓰기 대신)을 덮어 쓰지 마십시오.

이러한 "중간 백업"전략이 합리적인 옵션 인 경우 궁극적으로 응용 프로그램 및 해당 아키텍처와 관련 데이터의 특성 및 구조에 따라 달라집니다. 그러나 사용자가 10 분 미만의 작업을 잃어 버리고 이러한 충돌이 일주일에 한 번 이상 발생하는 경우 거의 생각하지 않을 것입니다.


10
en.wikipedia.org/wiki/Crash-only_software로 Android 앱이 필요에 따라 작동하는 방식입니다.
Mooing Duck

3
훌륭한 답변-더 넓은 맥락에서 사물을 고려하는 좋은 예 (이 경우 "충돌 발생시 데이터 손실을 어떻게 방지 할 수 있습니까?")가 더 나은 솔루션을 제공합니다.
썰매

1
오래된 데이터를 덮어 쓰면 안된다는 점을 약간 수정했습니다. 걱정하지 않기를 바랍니다.
썰매

1
@MooingDuck 많은 Android 앱 (예 : 게임)이 충돌시 상태를 잃습니다.
user253751

1
@immibis : 그렇습니다. Android에는 실제로 저품질 앱이 많이 있습니다.
Mooing Duck

30

개발중인 응용 프로그램에 어느 정도 의존하지만 일반적으로 응용 프로그램에 처리되지 않은 예외가 발생하면 종료해야한다고 말하고 싶습니다.

왜?

더 이상 응용 프로그램 상태에 대해 확신 할 수 없기 때문입니다.

확실히, 유용한 메시지를 사용자 에게 제공 하지만 궁극적으로 응용 프로그램을 종료해야합니다.

귀하의 상황을 감안할 때 분명히 응용 프로그램을 종료하고 싶습니다. 실험실에서 실행중인 소프트웨어가 손상된 출력을 생성하는 것을 원하지 않으며 예외를 처리 할 생각이 없었기 때문에 예외가 발생한 이유와 발생 원인을 알 수 없습니다.


마지막 부분에서 응용 프로그램에 대한 컨텍스트 정보를 추가하려고했습니다.
조나스 벤츠

10
@JonasBenz 사용자가 응용 프로그램을 다시 시작하기 전에 저장할 수 있으면 더 좋지 않습니까? 예, 그러나 사용자가 저장할 데이터가 유효하고 손상되지 않은지 어떻게 알 수 있습니까? 이 시점에서 예기치 않은 예외가 발생하여 이유를 모릅니다. 사용자에게는 귀찮지 만 가장 안전한 방법은 응용 프로그램을 종료하는 것입니다. 사용자 절약 작업이 걱정된다면 지속적인 절약 전략을 사용하십시오. 다시 말하지만, 그것은 모두 작성중인 응용 프로그램에 달려 있습니다.
매튜

4
예, 여기서도 같은 방식으로 논쟁 할 수 있습니다. 계속 버튼의 존재에 동의하지 않습니다. 문제는 단순히 응용 프로그램 개발자가 안전하게 계속할 수 있는지 알 수 없다면 사용자는 어떻게 알 수 있습니까? 처리되지 않은 예외가 발생하면 예상치 못한 오류가 발생하여이 시점에서 무슨 일이 일어나고 있는지 확실하게 말할 수 없다는 의미입니다. 사용자는 작업을 잃고 싶지 않기 때문에 계속하고 싶을 것입니다.하지만이 오류로 인해 응용 프로그램이 나쁜 결과를 낳을 수 있다고해도 계속 하시겠습니까?
매튜

3
@Matthew "만약 당신이 애플리케이션 개발자가 안전하게 계속할 수 있는지, 사용자가 어떻게 알 수 있는지 모른다면" 개발자는 언제 코드를 작성했는지 알 수 없었습니다. 사용자가 이와 같은 특정 버그를 발견하면 알려진 것일 수 있습니다. 그리고 사용자는 어떤 사용자 포럼, 지원 채널 및 기타 정보에서 찾을 수 있거나 단순히 데이터에 어떤 일이 발생하는지 테스트하고보고 ... "계속"이 적절한 지 사용자가 실제로 알 수 있습니다.
하이드

1
@JonasBenz의 Windows 3.1에서 프로그램이 잘못된 메모리 액세스를 수행 할 때 나타나는 대화 상자에는 프로그램을 계속 실행할 수있는 "무시"단추가있었습니다. 이후 버전의 모든 Windows에는 해당 버튼이 없습니다.
마크

12

이는 화학 실험 실용이며 애플리케이션이 계측기를 직접 제어하지 않고 다른 서비스를 통해 제어한다는 것을 고려하십시오.

메시지를 표시 한 후 강제 종료하십시오. 처리되지 않은 예외 후에 응용 프로그램이 알 수없는 상태입니다. 잘못된 명령을 보낼 수 있습니다. 코 악마를 불러 일으킬 수도 있습니다 . 잘못된 명령은 잠재적으로 고가의 시약이나 장비 또는 사람들에게 가져다 위험을 낭비 할 수 있습니다 .

그러나 다른 작업을 수행 할 수 있습니다 . 다시 시작한 후 정상적으로 복구 합니다. 응용 프로그램이 충돌 할 때 백그라운드 서비스를 자체적으로 중단하지 않는다고 가정합니다. 이 경우 상태를 쉽게 복구 할 수 있습니다. 또는 더 많은 상태가있는 경우 저장을 고려하십시오. 데이터 원자 성과 무결성 (SQLite 어쩌면?)을 제공하는 스토리지

편집하다:

의견에 명시된 바와 같이, 제어하는 ​​프로세스에는 사용자가 반응 할 시간이 없을 정도로 빠르게 변경해야 할 수 있습니다. 이 경우 정상 상태 복구 외에 앱을 자동으로 다시 시작하는 것을 고려해야합니다.


지금 바로 후속 명령이 필요한 상태에서 종료하는 것은 화학 실험실에서와 마찬가지로 위험 할 수 있습니다.
Oleg V. Volkov

@ OlegV.Volkov 그래서 종료시 스스로 다시 시작할 수 있습니까? 알맞은 컴퓨터에서 GUI를 시작하면 수백 밀리 초 정도 걸립니다. 프로세스에 더 어려운 타이밍이 필요한 경우 비 실시간 OS에서는 제어가 구현되지 않습니다. 최종 위험 평가를 수행해야하는 것은 OP이지만
Jan Dorniak

@ OlegV.Volkov 그것은 좋은 지적이므로 답변에 그것에 대한 의견을 추가했습니다.
Jan Dorniak

8

프로그램의 최상위 레벨에서이 질문에 일반적으로 답하려고하는 것은 현명한 플레이가 아닙니다.

무언가가 완전히 터져 나 응용 프로그램의 아키텍처에서 아무도이 사례를 고려하지 않았다면 어떤 조치를 취하거나 안전하게 수행 할 수 있는지에 대한 일반화가 없습니다.

따라서, 응용 프로그램과 개발자가 가능한지 또는 현명한 지 알아내는 데 필요한 실사를 실증적으로 수행하지 않았기 때문에 사용자가 응용 프로그램의 복구 시도 여부를 선택할 수있는 것은 일반적으로 허용되는 디자인이 아닙니다. .

그러나 응용 프로그램에 이러한 종류의 오류 복구를 염두에두고 설계된 논리 나 동작의 가치가 높은 부분이 있다면이 경우에 활용할 수 있습니다. 사용자에게 복구를 시도 할 것인지 또는 전화를 끊고 다시 시작하길 원하는지 묻는 메시지가 표시 될 수 있습니다.

이러한 종류의 복구는 일반적으로 모든 (또는 대부분의) 프로그램에 필요하거나 권장되지는 않지만, 이러한 정도의 운영 무결성이 필요한 프로그램에서 작업하는 경우 이러한 종류의 복구를 나타내는 상황 일 수 있습니다. 사용자에게 프롬프트하는 것은 제정신이 아닌 일입니다.

특수한 오류 복구 논리를 대신하여-아니요,이 작업을 수행하지 마십시오. 당신은 말 그대로 무슨 일이 일어날 지 전혀 알지 못합니다. 그렇다면 예외를 더 잡아서 처리했을 것입니다.


불행히도, "일부 위치에서 수신 한 데이터로 객체를 빌드하는"과 같은 많은 방법은 작업을 완료 할 수 없다는 것을 나타내는 예외를 구분하지 않지만 더 심각한 것을 나타내는 방법과는 아무런 부작용이 없었습니다. 잘못되었습니다. 리소스를로드하려는 시도가 어떤 이유로 예상하지 못한 이유로 실패했다는 사실은 일반적으로 객체를 구성 할 수없는 경우에 치명적인 오류를 강요해서는 안됩니다. 중요한 것은 부작용입니다. 불행히도 예외 프레임 워크는 무시합니다.
supercat

@supercat-오류를 식별 할 수 있으면 처리 할 수 ​​있습니다. 식별 할 수없는 경우 응용 프로그램 상태에서 무결성 검사를 실행하여 잘못되었을 수있는 사항을 알아 내려고 루틴을 작성하지 않으면 처리 할 수 ​​없습니다. 오류가 무엇인지는 중요하지 않습니다. 우리는 일반적으로 잡히지 않은 예외를 처리하려고한다는 사실을 알지 못한다는 것을 분명히 밝혔습니다.
Iron Gremlin

3

"예외 예외", 즉 예상치 못한 예외와 같은 문제는 프로그램의 상태를 알 수 없다는 것입니다. 예를 들어, 사용자의 데이터를 저장하려고하면 실제로 더 많은 데이터파괴 될 수 있습니다 .

따라서 응용 프로그램을 종료해야합니다.

George Candea와 Armando Fox의 Crash-only Software 라는 흥미로운 아이디어가 있습니다 . 아이디어를 닫을 수있는 유일한 방법은 소프트웨어를 중단하고 시작하는 유일한 방법은 충돌에서 복구하는 것만으로 소프트웨어를 설계하면 소프트웨어의 복원력이 향상되고 오류 복구가 가능해집니다. 코드 경로는 훨씬 철저하게 테스트되고 연습됩니다.

일부 시스템 은 충돌 후 순서대로 종료 한 후보다 더 빨리 시작되었다는 사실을 알게 된 후이 아이디어를 생각해 냈습니다 .

더 이상 적절한 예는 아니지만, 이전 버전의 Firefox는 충돌로부터 복구 할 때 더 빨리 시작될뿐만 아니라 시작 환경향상되었습니다 . 이 버전에서 Firefox를 정상적으로 종료하면 열려있는 모든 탭이 닫히고 하나의 빈 탭으로 시작됩니다. 충돌에서 복구하는 경우 충돌시 열린 탭이 복원됩니다. (그리고 이것이 현재 브라우징 컨텍스트를 잃지 않고 Firefox를 닫을 수있는 유일한 방법이었습니다.) 그래서 사람들은 무엇을 했습니까? 그들은 단순히 Firefox를 닫지 않고 대신 항상 Firefox를 종료 pkill -KILL firefox했습니다.

Linux Weekly News의 Valerie Aurora의 크래시 전용 소프트웨어에 대한 훌륭한 글 이 있습니다 . 의견도 읽을 가치가 있습니다. 예를 들어, 의견을 제시 한 사람은 그러한 아이디어가 새로운 것이 아니며 실제로 Erlang / OTP 기반 응용 프로그램의 디자인 원칙과 다소 유사하다고 지적합니다. 물론 Valerie와 10 년이 지난 후 그리고 원래 기사 이후 15 년이 지난 지금 이것을 살펴보면 현재의 마이크로 서비스 광고가 다시 같은 아이디어를 다시 발명하고 있음을 알 수 있습니다. 현대 클라우드 규모의 데이터 센터 설계는 또한 더 세분화 된 세분화의 예입니다. (시스템에 영향을주지 않고 언제든지 모든 컴퓨터가 충돌 할 수 있습니다.)

그러나 소프트웨어를 중단시키는 것만으로는 충분하지 않습니다. 그것을 위해 설계되어야합니다. 이상적으로 소프트웨어는 각각 독립적으로 충돌 할 수있는 작은 독립적 인 구성 요소로 나뉩니다. 또한 "충돌 메커니즘"은 충돌하는 구성 요소 외부에 있어야합니다.


1

대부분의 예외를 처리하는 올바른 방법은 결과적으로 손상된 상태에있을 수있는 개체를 무효화하고 무효화 된 개체가이를 방지하지 않으면 계속 실행하는 것입니다. 예를 들어, 리소스를 업데이트하기위한 안전한 패러다임은 다음과 같습니다.

acquire lock
try
  update guarded resource
if exception
  invalidate lock
else
  release lock
end try

보호 된 리소스를 업데이트하는 동안 예기치 않은 예외가 발생하면 리소스가 손상된 상태로 추정되고 예외가 다른 유형의 예외인지 여부에 관계없이 잠금이 무효화됩니다.

불행히도, IDisposable/ using를 통해 구현 된 리소스 가드 는 블록이 정상적으로 또는 비정상적으로 종료되었는지 알 수있는 방법없이 보호 된 블록이 종료 될 때마다 해제됩니다. 따라서 예외 이후에 언제 계속해야하는지에 대한 명확한 기준이 있어야하지만 적용시기를 알 수있는 방법은 없습니다.


적절한 방법이 무엇인지에 대한 상대적으로 명백하지 않은 여전히 ​​일반적인 관점을 표현하기 위해 +1. 나는 그것이 내가 참신한 휴리스틱 / 규칙이기 때문에 실제로 그것에 동의한다면 아직 모른다. 그래서 잠시 동안 그것을 극복해야하지만 그럴듯하게 보입니다.
mtraceur

0

모든 단일 iOS 및 MacOS 앱이 따르는 접근 방식을 사용할 수 있습니다. 포착되지 않은 예외는 애플리케이션을 즉시 중단시킵니다. 또한 범위를 벗어난 배열 또는 최신 응용 프로그램의 산술 오버플로와 같은 많은 오류가 동일합니다. 경고가 없습니다.

내 경험상 많은 사용자가 통지를하지 않고 앱 아이콘을 다시 탭하면됩니다.

분명히 이러한 충돌이 심각한 데이터 손실로 이어지지 않고 비용이 많이 드는 실수로 이어지지 않도록해야합니다. 그러나“지금 앱이 다운 될 것입니다. 귀찮게된다면 지원 센터에 전화하십시오”라고 말하지 마십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.