답변:
기술적으로 첫 번째는 메시지가로 설정된 RuntimeError를 발생 "foo"시키고 두 번째는 메시지가로 설정된 Exception을 발생시킵니다 "foo".
실제로 전자를 사용하려는 경우와 후자를 사용하려는 경우에는 상당한 차이가 있습니다.
단순히 당신이 아마 원하는 넣어 RuntimeError없습니다 Exception. 인수가없는 구조 블록 RuntimeErrors은를 잡지 만 Exceptions를 잡지는 않습니다 . 따라서 Exception코드에서를 발생 시키면이 코드는이를 포착하지 못합니다.
begin
rescue
end를 잡으려면 Exception다음을 수행해야합니다.
begin
rescue Exception
end이는 어떤 의미 에서는를 복구하기 위해 더 많은 작업을 수행해야하기 때문에는 Exception보다 "더 나쁜"오류 임을 의미 RuntimeError합니다.
따라서 원하는 것은 프로젝트에서 오류 처리를 수행하는 방법에 따라 다릅니다. 예를 들어, 데몬에서 메인 루프에는를 잡아서 RuntimeErrors보고 한 다음 계속 하는 빈 구조가 있습니다. 그러나 한두 가지 상황에서 데몬이 실제로 오류로 죽기를 원하며,이 경우 Exception"일반 오류 처리 코드"를 통해 곧바로 나가는를 발생시킵니다.
당신이 라이브러리 코드를 작성하는 경우 그리고 다시, 당신은 아마 원하는 RuntimeError아닌 Exception, 그것은 오류를 제기하는 경우 라이브러리의 사용자가 놀라게 될 것이다 빈 그 rescue블록이 잡을 수 없어, 그리고 그들에게 이유를 실현하기 위해 잠시 시간을내어됩니다.
마지막 RuntimeError으로이 클래스의 하위 클래스 라고 말해야합니다. StandardError실제 규칙은 raise 모든 유형의 객체 를 사용할 수 있지만 rescue기본적으로 StandardError. 다른 모든 것은 구체적이어야합니다.
StandardError. 같은 몇 줄보다 더 복잡 할 필요는 없습니다 class MissingArgumentsError < StandardError; end.
raise
raise( string )
raise( exception [, string [, array ] ] )인수없이 예외를 발생 $!시키거나 RuntimeErrorif $!가 nil 인 경우 를 발생시킵니다. 단일 String인수로 RuntimeError문자열을 메시지로 사용하여 a를 발생시킵니다. 그렇지 않으면 첫 번째 매개 변수는 Exception클래스 의 이름 (또는 Exception전송시 예외 를 반환하는 객체) 이어야합니다 . 선택적 두 번째 매개 변수는 예외와 관련된 메시지를 설정하고 세 번째 매개 변수는 콜백 정보의 배열입니다. 예외는 begin...end블록 의 구조 절에서 포착됩니다 .
raise "Failed to create socket"
raise ArgumentError, "No parameters", caller
RuntimeError < StandardError < Exception[2] 따라서, 코드의 두 번째 블록이 있다는 것입니다 예외와 RuntimeError에 [3] 모두를 잡을 "베어"발생 및 구조가 특정 예외와 함께 작동하는 것이 흥미 롭거나 이상합니다. [4] 아마도 경험의 법칙은 RuntimeError를 클라이언트 코드에 발생시키는 것이지만, 자신의 코드 내에서 사용자 지정 예외를 발생시키고 구조하는 것입니까?