2012-03-04 3 views
1

내가 WebCrawler 클래스라고 가정합니다. 발생할 수있는 몇 가지 오류가 있습니다. 오류를 어떻게 전파해야합니까?사용자 정의 예외를 발생 시키거나 상수를 반환하거나 기호를 반환 하시겠습니까? 왜?

사용하여 예외 :

class WebCrawler 
    class UrlBadFormatError < StandardError; end 
    class PageNotFoundError < StandardError; end 
    class UnauthorizedError < StandardError; end 
    def crawl(url) 
    if(! url =~ /some_format/) 
     raise UrlBadFormatError 
    response = get(url) 
    if(response.code == 404) 
     raise PageNotFoundError 
    if(response.code == 403) 
     raise UnauthorizedError 
    ... 
    end 
end 

또는 상수 :

class WebCrawler 
    URL_BAD_FORMAT = 1 
    PAGE_NOT_FOUND = 2 
    UNAUTHORZIED = 3 
    def crawl(url) 
    if(! url =~ /some_format/) 
     return URL_BAD_FORMAT 
    response = get(url) 
    if(response.code == 404) 
     return PAGE_NOT_FOUND 
    if(response.code == 403) 
     return UNAUTHORZIED 
    ... 
    end 
end 

또는 기호 : 최고

class WebCrawler 
    def crawl(url) 
    if(! url =~ /some_format/) 
     return :url_bad_format 
    response = get(url) 
    if(response.code == 404) 
     return :page_not_found 
    if(response.code == 403) 
     return :unauthorized 
    ... 
    end 
end 

? 또는 무엇에 의존 하는가 (무엇인가?)

답변

2

잘못된 형식의 인수가 메서드에 전달 된 것과 같이 프로그래머 오류를 나타내는 무언가에 대해서는 예외가 발생합니다. 예외가 발생하면 프로그램이 중단되어 클래스를 잘못 사용하고 있다는 사실에 프로그래머가주의를 환기시켜 문제를 해결할 수 있습니다. 이 경우 반환 값을 확인하는 코드가 프로그램에 포함되어야하기 때문에 오류 코드를 반환하는 것은 의미가 없지만 프로그램이 디버깅 된 후에는 이러한 오류가 발생하지 않아야합니다.

WebCrawler 클래스의 경우 이 맞는지crawl은 때때로 잘못된 URL을 인수로 사용합니까? 나는 그 대답이 아마도 아니오라고 생각한다. 따라서 잘못된 URL을 전달할 때 예외를 발생시키는 것이 적절할 수 있습니다.

예외가 발생하면 갑자기 실행 흐름이 가장 안쪽의 처리기로 "이동"합니다. 대부분의 경우에 예외가 이 아닐 때 코드를 구조화하는 유용한 방법이 될 수 있습니다. 왜냐하면 대부분의 경우에 많은 세부 사항을 포함하지 않고 간단하고 직선적 인 코드로 메소드의 "메인 플로우"를 작성할 수 있기 때문입니다. 드문 오류 상황이 발생할 때 어떤 일이 발생합니다. 이러한 세부 정보는 "기본 흐름"코드와 분리되어 예외 처리기에 넣을 수 있습니다. 그러나 정상 조건에서 오류 조건이 발생할 것으로 예상되는 경우 오류 처리 코드를 "주 흐름"과 함께 인라인으로 배치하여 진행 상황을 명확하게하는 것이 좋습니다. 프로그램의 제어 흐름이 (정상적인 흐름 제어에 예외가 사용되는 경우와 같이) "뛰어 오르는"경우, 독자는 프로그램 텍스트에서 어떻게 작동하는지 파악할 때 "뛰어 넘어야"한다는 의미입니다.

다른 두 가지에 대해서는 적어도 때때로 HTTP 요청이 오류 코드를 반환 할 것으로 예상됩니다. 예외 또는 특수 반환 값이 그러한 조건을 나타내는 가장 좋은 방법인지 여부를 확인하려면 의 빈도는 보통이고 정상적인 사용에서는 이러한 조건이 발생한다고 생각합니다. 클라이언트 코드가 어떻게 읽히는 지 생각해보십시오. 당신이 예외를 사용하는 경우, 그들은 같은 것을 작성해야합니다

urls.map do |url| 
    begin 
    crawl(url) 
    rescue PageNotFoundError 
    "" 
    rescue UnauthorizedError 
    "" 
    end 
end 

이 (그건 그렇고,이 코드의 예를 생각하는 것은 무엇인가를 보여줍니다 사용자 정의 예외 모두가 공통의 슈퍼 클래스에서 상속하는 경우 그것은 좋은 생각이 될 수도 있습니다 . 단일 rescue 절을 둘 다 잡을 수 있도록, 필요한 경우) 또는 오류 코드를 사용하는 경우, 그것은과 같이 보일 것이다 : 당신이 생각하십니까 더 읽고

urls.map do |url| 
    response = crawl(url) 
    if [:page_not_found, :unauthorized].include? response 
    "" 
    else 
    response 
    end 
end 

를? 그것은 당신에게 달려 있습니다. 당신이하는 한 가지가 이 아니라이 원하는 것은 오류에 정수 상수를 사용하는 것입니다. 정수를 사용하는 이유는 무엇입니까? 디버그 추적에서이를 인쇄 할 때 각각의 의미를 확인하려면 상수 목록을 살펴 봐야합니다. 그리고 기호를 사용하는 것만으로도 계산이 효율적입니다.

0

예외 인 경우 예외가 발생했습니다. 이 세 가지 사례는 모두 제 의견으로는 예외입니다. 일부 사람들은 4xx 상태 코드가 예외적으로 발생하지 않을 가치가 있다고 주장 할 수도 있지만 여전히 클라이언트 오류입니다. 당신은 또한에 대해 읽을 수 있습니다

(나는 그런 경우가 여기에 생각하지 않습니다하지만) 적용 "제어 흐름에 대한 예외를 사용하지 않는"경우에 대한 예외와 같은 동작을 제공 루비의 throw/catch.

2

이 아닌 경우 예외가 발생합니까? 그들은 유형 외에 추가 정보를 캡슐화 할 수 있고, 쉽게 구제받을 수 있으며 IDE를 사용하는 경우 일류 시민입니다.

+5

IDE를 사용하는지 여부는 * how * 또는 * what * 프로그램에서 고려해야한다고 생각하지 않습니다. –

+2

@AndrewMarshall 그건 하나의 관점이지만, 실제로 중요 할 수 있습니다. –

+3

문체/문서 규칙 (문자 그대로의 코드에는 실제로 영향을주지 않습니다) 이외에는 안됩니다. IDE를 사용하든 IDE를 사용하든 관계없이 일류 시민이 아닌 예외는 (클래스에 의한 것임을 가정하면) 사실입니다. –

0

오류가 발생해야합니다. 잘못된 URL이 있거나 페이지를 찾을 수 없거나 해당 페이지에 대한 액세스 권한이없는 경우 크롤링을 계속할 수 없음을 의미합니다. 메소드에서 오류 또는 예외를 발생 시키면 호출자가 비정상적인 상황을 처리 할 수 ​​있습니다.

또한 오류 코드, 오류가 발생한 URL 및 기타 관련 정보와 같은 오류에 대한 정보도 포함해야합니다. 오류를 가장 잘 처리 할 수있는 방법을 결정하는 데 도움이 될 수 있으며 나중에 사용자에게 도움이되는 메시지로 형식을 지정할 수 있습니다.

무엇을 하면 안되며,은 숫자 오류 코드입니다. 루비는 C가 아닙니다. 대신 심볼을 사용하십시오.

-1

웹상에 403, 404, 잘못된 URL 및 유사한 흔히있는 문제가 발생하면 예외 사용을 반대합니다. 예외는 "내부"오류를 의미합니다. World Wild Web에서 잘못된 URL은 전혀 예외가 아닙니다. 각기 다른 URL 질병을 처리하기위한 방법이 있어야합니다. 개인적으로 기호로 값을 반환하거나, 일어난 일을 기록하는 "SpecialCase"개체를 반환합니다. 또한 사용되지 않는 catch ... throw 문이 있습니다.

+1

오류가 많이 발생하기 때문에 예외는 아닙니다. 배터리가 방전 되었기 때문에 자동차가 시동을 걸지 않는다면 정상적인 동작입니다. 그렇지만 문제를 해결하기 위해서는 특별한 경우가 필요합니다. 나쁜 습관을 모범 사례와 혼동하지 마십시오. 통신 실패는 아무리 자주 발생하더라도 예외입니다. 실패! = 성공. – ocodo

+0

내 대답에서 내 이유가 분명하지 않기 때문에 어쩌면 결국별로 좋지 않을 수도 있습니다 .- 무엇보다 나쁜 것은 스스로 잊었습니다 .--) 그러나 내 습관은 내가 예외를 좋아하는 것처럼 비난하지 않아야합니다. 배터리는 평평하지만 가로등이 빨간색 일 때도 마찬가지입니다. [이에 관한 한 가지 논의가 있습니다] (http : // stackoverflow.com/questions/2018137), HTTP 예외에 대한 catch/throw를 사용하여 Sinatra를 명시 적으로 언급하고 [다른 하나를 시작했습니다] (http://stackoverflow.com/questions/16972757). 잡기/던지기가 정말 안좋은가? –

관련 문제