AppSignal에서는 Ruby 애플리케이션에 대한 오류 추적을 제공합니다. 이를 위해 우리는 애플리케이션에서 발생하는 모든 예외를 포착하고 해당 예외가 발생하면 개발자에게 알립니다.
예외 처리를 올바르게 수행하는 것은 어려울 수 있습니다. 이 글에서는 이것이 어떻게 작동하는지, 잘못 처리하면 어떤 문제가 발생할 수 있는지, 예외를 적절하게 복구하는 방법에 대해 설명합니다.
예외 구조
Ruby에서 예외를 복구하면 문제가 발생하는 순간 애플리케이션이 충돌하는 것을 방지할 수 있습니다. begin .. rescue 사용 블록을 사용하면 오류가 발생할 때 애플리케이션에 대한 대체 경로를 지정할 수 있습니다.
어떤 예외를 복구해야 하는지 지정하는 것도 가능합니다. 예외 클래스를 지정하면 이 예외의 모든 하위 클래스도 캡처됩니다.
위의 예에서는 Errno::ENOENT 예외를 볼 수 있습니다. 상위 SystemCallError일 때 포착됩니다. 구조되고 있습니다.
예외 체인에서 너무 높은 위치에 있는 구조
예외 체인에서 너무 높은 위치에 예외를 구조하지 않는 것이 중요합니다. 그렇게 하면 하위 클래스로 분류된 모든 예외도 포착되어 구조 블록의 캡처가 너무 일반적이게 됩니다.
다음은 프로그램에 전달된 인수를 기반으로 구성 파일을 읽는 프로그램입니다.
오류 메시지에는 구성 파일을 읽을 수 없다고 나와 있지만 실제 문제는 코드의 오타였습니다.
begin .. rescue에 의해 포착된 기본 예외 클래스 블록은 StandardError입니다. 특정 클래스를 전달하지 않으면 Ruby는 StandardError와 모든 하위 클래스 오류를 복구합니다. NoMethodError는 이러한 오류 중 하나입니다.
특정 예외 클래스를 복구하면 관련 없는 오류가 실수로 실패 상태를 표시하는 것을 방지하는 데 도움이 됩니다. 또한 최종 사용자에게 더욱 도움이 되는 보다 구체적인 사용자 정의 오류 메시지를 제공할 수 있습니다.
예외 구제
예외 체인의 상위 계층을 구출하는 것은 여전히 유혹적일 수 있습니다. 애플리케이션에서 발생할 수 있는 모든 오류를 복구하면 애플리케이션 충돌을 방지할 수 있습니다. (가동 시간 100% 달성!) 하지만 많은 문제가 발생할 수 있습니다.
Exception 클래스는 Ruby의 주요 예외 클래스입니다. 다른 모든 예외는 이 클래스의 하위 클래스입니다. 예외가 구제되면 모든 오류가 포착됩니다.
대부분의 애플리케이션이 복구하고 싶지 않은 두 가지 예외는 SignalException과 SystemExit입니다.
SignalException은 외부 소스가 애플리케이션을 중지하라고 지시할 때 사용됩니다. 종료하려는 운영 체제일 수도 있고 응용 프로그램을 중지하려는 시스템 관리자일 수도 있습니다. 예시
SystemExit는 exit일 때 사용됩니다. Ruby 애플리케이션에서 호출됩니다. 이 문제가 발생하면 개발자는 애플리케이션이 중지되기를 원합니다. 예시
예외를 구출하고 애플리케이션이 현재 begin ... rescue ... end를 실행하는 동안 이러한 예외가 발생하는 경우 차단하면 종료할 수 없습니다.
일반적인 상황에서 Exception을 구출하는 것은 일반적으로 좋지 않은 생각입니다. Exception을 복구하면 SignalException 및 SystemExit가 작동하지 않게 될 뿐만 아니라 LoadError, SyntaxError 및 NoMemoryError도 방지됩니다. 대신 좀 더 구체적인 예외를 구출하는 것이 더 좋습니다.
테스트 실패
예외가 구조되면 rescue Exception => e를 사용합니다. , 애플리케이션 이외의 다른 것들도 중단될 수 있습니다. 테스트 스위트는 실제로 일부 오류를 숨기고 있을 수 있습니다.
minitest 및 RSpec 어설션이 실패하면 예외가 발생하여 실패한 어설션에 대해 알리고 테스트가 실패합니다. 그렇게 하면 Exception에서 하위 클래스로 분류된 자체 사용자 정의 예외가 발생합니다.
테스트나 애플리케이션 코드에서 예외가 구조되면 어설션 실패가 침묵될 수 있습니다.
예외 발생
일부 코드는 예외를 발생시키기 위한 것입니다. 테스트 스위트에서는 예외가 발생할 때 테스트가 실패하지 않도록 하기 위해 예외를 간단히 침묵시키는 것이 가능합니다.
그러나 예외가 발생했는지 여부는 테스트하지 않습니다. 예외가 발생하지 않으면 테스트에서는 동작이 여전히 올바른지 알 수 없습니다.
예외가 발생했는지, 그렇지 않은 경우 어떤 예외가 발생했는지 주장하는 것이 가능합니다.
예외 재발생
애플리케이션은 매우 타당한 이유가 있는 경우 체인에서 Exception 클래스만큼 높은 예외만 캡처해야 합니다. 예를 들어 실제로 제거해야 하는 임시 파일을 제거하는 등 코드 블록을 종료하기 전에 일부 정리 작업이 필요한 경우입니다.
예외를 반드시 구출해야 하는 경우에 대한 한 가지 권장 사항은 오류 처리를 마친 후 예외를 다시 발생시키는 것입니다. 이렇게 하면 Ruby 예외 처리가 이후 프로세스의 운명을 결정할 수 있습니다.
무엇을 구해야 할지 모르시나요?
앞서 언급했듯이 어떤 오류를 복구할지 구체적으로 지정하는 것이 좋습니다.
작업에서 어떤 예외가 발생할 수 있는지 확실하지 않은 경우 StandardError를 구출하는 것이 좋은 시작점이 될 수 있습니다. 다양한 시나리오에서 코드를 실행하고 어떤 예외가 발생하는지 확인하세요.
새로운 예외가 발생할 때마다 해당 예외 또는 관련 상위 클래스에 대한 특정 구조 사례를 추가하세요. 너무 많은 예외를 구제하는 것보다 무엇을 구제할지 구체적으로 지정하는 것이 좋습니다.
이것으로 Ruby의 예외 처리에 대한 입문서를 마칩니다. 더 알고 싶거나 구체적인 질문이 있는 경우 @AppSignal로 알려주시기 바랍니다. 앱에서 예외가 발생하는 위치와 빈도에 대해 더 나은 통찰력을 얻으려면 AppSignal을 사용해 보세요.
