«exception-handling» 태그된 질문

예외 처리는 특수 처리가 필요한 예외적이거나 예외적 인 조건이 발생하는 경우 (일반적으로 프로그램 실행의 흐름이 변경됨)에 대응하는 프로세스입니다.

9
오류 처리-프로그램이 오류로 실패하거나 자동으로 무시하는 경우
네트워크를 통해 MIDI를 전송하는 간단한 작은 프로그램을 작성 중입니다. 프로그램에서 전송 문제 및 / 또는 예측할 수없는 기타 예외 상황이 발생한다는 것을 알고 있습니다. 예외 처리의 경우 두 가지 접근 방식이 있습니다. 프로그램을 작성해서 작성해야합니다. 무언가 잘못되었을 때 뱅으로 실패 하거나 데이터 무결성을 희생하면서 오류를 무시하고 계속해야합니까? 사용자는 어떤 접근법을 …

10
왜 예외 대신에 버그라는 단어를 사용하지 않습니까? [닫은]
휴무 . 이 질문은 의견 기반 입니다. 현재 답변을받지 않습니다. 이 질문을 개선하고 싶습니까? 이 게시물 을 편집 하여 사실과 인용으로 답변 할 수 있도록 질문을 업데이트하십시오 . 휴일 오년 전에 . 예외를 버그라고한다면, 예외 대신 우선 버그라고 부르지 않겠습니까? 코드에서 예외라고하며 발생하자마자 버그라고합니다. 그렇다면 왜 먼저 버그라고 부르지 않습니까? …

3
스칼라에서 확인되지 않은 예외에 대한 결정
Java 프로그래머로서, 나는 항상 점검되지 않은 예외를 비판했습니다. 대부분의 프로그래머는 나중에 쉽게 문제를 일으킬 수 있도록 코딩 편의를위한 경로로 사용합니다. 또한 예외를 확인한 프로그램 (단순하지는 않지만)은 확인되지 않은 상대방에 비해 훨씬 강력합니다. 놀랍게도 스칼라에는 Checked Exceptions라는 것이 없습니다. 스칼라에서는 모든 Java가 선택 및 선택 해제되어 있습니다. 이 결정의 동기는 무엇입니까? …

2
추상 예외 슈퍼 타입
던지기 System.Exception가 그렇게 나쁘다고 여겨 지면 왜 처음부터 Exception만들어 지지 않았 abstract습니까? 그렇게하면 전화를 걸 수 없습니다. throw new Exception("Error occurred."); 이렇게하면 파생 된 예외를 사용하여 발생한 오류에 대한 자세한 정보가 제공됩니다. 예를 들어 라이브러리에 사용자 정의 예외 계층을 제공하려는 경우 일반적으로 예외에 대한 추상 기본 클래스를 선언합니다. public abstract …


1
기본 생성자를 사용할 수 없게 만드는 것이 좋습니까?
기본 생성자에 대해 구체적으로 묻습니다. 생성자가 객체의 모든 데이터를 초기화한다고 가정하면, 적절한 초기화없이 사용할 수없는 클래스를 만들면 기본 생성자가 쓸모없는 경우가 아닌가? 치다: // A class for handling lines in a CSV file class CSV_Entry { private: unsigned num_entries; std::string string_version; std::vector<std::string> vector_version; ...etc public: CSV_Entry(); CSV_Entry(const std::string& src_line); // …

6
대체를위한 중첩 된 try-catch에 대한 대안
객체를 검색하려고하는 상황이 있습니다. 조회가 실패하면 몇 가지 폴 백이 있으며 각각 실패 할 수 있습니다. 따라서 코드는 다음과 같습니다. try { return repository.getElement(x); } catch (NotFoundException e) { try { return repository.getSimilarElement(x); } catch (NotFoundException e1) { try { return repository.getParentElement(x); } catch (NotFoundException e2) { //can't recover throw …

5
연중 무휴 24 시간 실행해야하는 프로그램에서 예외 처리
처리 할 수있는 예외 만 잡아야한다는 것을 읽었으며 기본 예외 클래스 (이 경우 C #)를 잡는 것은 나쁜 생각입니다 (다른 이유로). 나는 현재까지 아직 예외가 발견되지 않은 것을 아직 보지 못한 프로젝트의 일부입니다. 그렇게하는 것은 나쁜 습관으로 여겨지지만 "이 서비스는 연중 무휴 24 시간 실행해야하므로 그렇게해야합니다."라고 대답했습니다. 연중 무휴 24 …

3
시스템 오류 노출 / 허용 / 복구에 대한 설계 패턴 / 접근법 권장, 예외 처리 (예 : Java, C ++, Perl, PHP)
시스템 오류 노출 / 허용 / 복구, 예외 처리 (Java, C ++, Perl, PHP)에 디자인 패턴 / 접근법을 추천 할 수 있습니까? 일부 오류가보고되어야합니다. 일부 오류는 내부적으로 처리 할 수 ​​있습니다 (재시도 또는 중요하지 않음 (무시 될 수 있음)). 코드를 잡기 위해 어떻게 코드를 구성합니까? 그러나 모든 오류를 기록해야합니다. 어떤 …

2
로거 실패를 어떻게 처리해야합니까?
회사의 여러 응용 프로그램에서 사용자 지정 로거를 사용합니다. 상당히 강력하지만 나중에 NLog와 같은 것으로 바꿀 수 있습니다. 로거의 작업 중 하나는 응용 프로그램에서 발생한 예외를 기록하는 것입니다. 내가 항상 가지고 있었던 한 가지 우려 는 로거 내 예외 처리 가 자동 실패를 허용한다는 것입니다. 즉, 로그가 주어진 예외에 대해 기록되지 …

5
쓸모없는 예외 처리로 코드 강화
코드의 다른 부분이 올바르게 코딩되지 않은 경우를 대비하여 쓸모없는 예외 처리를 구현하는 것이 좋은 방법입니까? 기본 예 간단한 것이므로 모든 사람들을 느슨하게하지는 않습니다 :). 데이터베이스에서 추출되는 개인 정보 (이름, 주소 등)를 표시하는 앱을 작성한다고 가정 해 보겠습니다. 내가 UI 부분을 코딩하는 사람이고 다른 사람이 DB 쿼리 코드를 작성한다고 가정 해 …

1
최고의 예외 처리 관행 또는 권장 사항? [닫은]
닫은. 이 질문은 주제에 맞지 않습니다 . 현재 답변을받지 않습니다. 이 질문을 개선하고 싶습니까? Software Engineering Stack Exchange에 대한 주제가 되도록 질문을 업데이트하십시오 . 휴일 오년 전에 . 내 프로그램의 두 가지 주요 문제는 코드 구조 / 구성 및 오류 처리라고 생각합니다. Code Complete 2를 읽고 있지만 잠재적 인 문제를 …

3
try-catch-finally 블록의 관련 코드가“얼마나 나쁜가?”
이것은 관련 Q : 반환 스타일이 나쁘거나 위험한 작업을 수행하기 위해 finally 절을 사용합니까? 참조 된 Q에서 finally 코드는 사용 된 구조 및 프리 페치의 필요성과 관련이 있습니다. 내 질문은 조금 다르며 더 많은 사람들에게 독창적이라고 생각합니다. 내 특정 예는 C # winform 앱이지만 C ++ / Java 최종 사용에도 …

8
유익한 예외와 깨끗한 코드의 균형을 맞추는 좋은 방법은 무엇입니까?
공개 SDK를 사용하면 예외가 발생하는 이유에 대한 정보를 제공하는 경향이 있습니다. 예를 들면 다음과 같습니다. if (interfaceInstance == null) { string errMsg = string.Format( "Construction of Action Argument: {0}, via the empty constructor worked, but type: {1} could not be cast to type {2}.", ParameterInfo.Name, ParameterInfo.ParameterType, typeof(IParameter) ); throw new …

4
catch를 사용하기 위해 의도적으로 예외 발생
if...else예외 처리로 래핑 된 일반적인 경우 다음 예제와 같이 코드 복제를 피하기 위해 권장되는 방법입니까? try { if (GetDataFromServer()) { return ProcessData(); } else { throw new Exception(); } catch(Exception ex) { return null; } 대신에... try { if (GetDataFromServer()) { return ProcessData(); } else { return null; } } …

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