틀렸어요. 너무 좋아요!예외로 처리하면

개시하다

C#의 개발은 UI/UX를 바탕으로 Forms, WPF, UWP, ASP로 나뉜다.NET 등이 있지만 잘 이뤄지면 책임의 범위와 배려, 신경 쓰는 부분도 늘어난다.
하지만 개발 대상이 복잡해져도 기본적인 일은 바뀌지 않는 곳도 있다.

DB 액세스

네트워크 연결

예외 처리

이번에는 이 예외 처리를 기술하자.

1. 기본 사양 결정 후 세부 설계

이 단계가 되면 실복을 의식하는 구상이 구체화된다.
영화와 드라마의 경우 장면, 캐릭터 배분, 볼거리 등을 한데 모았다.

기능과 작용이 명확해지다

각 단계의 기능, 역할에 따라 행위, 소지품(데이터)을 결정한다.
처리의 볼거리와 주요 기능이 연결되어 디버깅도 재미있고 쫄깃한 단계에 들어섰다
설치 오류를 발견하고 스타일이 누락된 것을 발견하는 바쁜 시기에 접어들었다.

설치 부분의 테스트 규격서를 기술하다.

그렇다면 이 단계가 바로 엔지니어로서 진정한 어려운 상태라는 각오를 하세요.

2. "잘못" 정보

오류를 실현하고 스타일 오류를 발견하는 등 테스트를 순조롭게 진행하는 것이 좋다.
여기서 다른 고장 원인을 예측하고 파악했는지 설명할 수 있습니까?

다음 내용은 자문자답!

"정상 시스템, 준정상 시스템, 이상 시스템은 얼마나 예상하여 대응할 수 있습니까?"

정상시스템...} 이거 규격에 맞으면 되나요?

준정상계··→ 이것은 규격에서도 0,-1,null이며 공백 시 덮어쓸 수 있음

이상계··→ 계산식의 0% 또는null 참조를 구상할 수 있고 기타 불안,

마지막 비정상적인 시스템의 망라와 구상 범위는 정말 C#의 구상을 덮어쓸 수 있습니까?
많은 프로그램 라이브러리는 구체적인 실시 상황을 볼 수 없기 때문에 예외적인 덮어쓰기가 있는지 파악하기 어렵다
또한 기존 DLL을 사용하여 자체 모듈 또는 개발한 부품을 사용하는 경우
규격에 따른 동작 외에 규격의 오류 처리나 이 정보를 전달할 수 있는지의 여부도 필요하다
너는 설계에 들어가는 것이냐, 아니면 뒷공정에 들어가는 사용자에게 편리한 것이냐를 생각해 볼 수 있니?

3. 예상치 못한 착오와 구상의 착오

영화와 드라마 이야기를 나누다 보면 가끔 NG 장면집이 나오는 프로그램이 있다.
보는 사람은 절로 웃기 시작하지만 제작 과정의 편집자는 촬영을 멈춰야 하는 장면이 발생한다.
확실히 C# 및 기타 언어는 예외입니다. 지속할 수 없는 NG가 발생했기 때문입니다.

예외가 생기다

특히 동작을 확인할 때 "~Exception 발생!"그래도 초보자에겐
나는 무엇을 어떻게 해야 할지, 원인도 모른다고 생각한다.
지나쳤을 때 갑자기'보통 보호 예외!'이런 사실이 알려지면 이용자들이 어떻게 해야 좋을지 모르는 상태에서 OS를 마음대로 내리고 재가동하는 시대도 있다.

의외의 착오로 인해 고장이 나지 않도록

예상치 못한 동작은 조작하는 사람과 관리하는 사람에게 부담을 준다.
규격에 따라 사용자의 컴퓨터 기술은 초보자의 수준으로 구상해야 한다.
용감한 자가 악용과 싸우면 갑자기 초기 경기장에서 초능력자를 만나게 된다.
누구든지 "이게 뭐야, 잠깐만."
영어권 사람이라면 This Appis a lemon.
(뜻: 이 앱은 불량품이다) 나쁜 인상을 줄 수 있겠지.

그럼 생각을 바꿔봅시다.

실수는 안 되지만 언제 일어날지 모르니 대응할 수 없다.
이 생각을 바꾸기 위해서는 잘못된 생각을 적극적으로 품어야 한다.
틀리지 않는 우등생의 실복이 아니라 "틀렸어 대박!"
이런 생각으로 접근하면 오류와 잘못된 동작을 관리하는 논리가 되기 때문에 앱으로서 오래 살 수 있다.
그리하여NET Framework를 따라해보는 건 어떨까요?
메서드 위에 마우스 커서를 놓으면 주석에서 발생할 수 있는 예외가 표시됩니다.

Runtime

// 概要:
//     Converts the string representation of a number to its 32-bit signed integer equivalent.
//
・・・
// 例外:
//   T:System.ArgumentNullException:
//     s is null.
//
//   T:System.FormatException:
//     s is not in the correct format.
//
//   T:System.OverflowException:
//     s represents a number less than System.Int32.MinValue or greater than System.Int32.MaxValue.
public static int Parse(string s)
{
    throw null;
}

가능한 오류 처리

잘못을 적극 저지르고 대책을 강구할 수 있다면
규격상 논리적으로 그 기재를 분류하고 명칭을 구별하다.
"틀렸어요. 너무 좋아요!"사상적으로 발생한 잘못을 예외로 삼다
다른 처리 메모리가 가득 차서 사용할 수 없기 때문에 HDD가 고장나서 접근이 불량할 것 같다
다른 책임은 잘못과 분리해서 사용한다.
주석에 논리적 제어 예외가 있다면
앞으로 사용할 모듈로도 신뢰받고 있습니다.무슨 일이 일어났는지 상상할 수 있는 범위는 안심할 수 있다.

끝말

예외를 교묘하게 다루면 비신인이나 초보자의 시선으로 받아들여지겠죠.
C# 기능이 업그레이드된 경우에도 오류 제거에 대한 반입 대응은 변경되지 않습니다.마우스 커서를 방법 위에 놓으면 예외를 알 수 있어 정말 편리하다.
어쨌든 실장할 때 간단히 확인할 수 있는 방법이기 때문에 이 마감 행동을 해주셨으면 좋겠습니다.