catch 블록을 사용하여 예외를 기록하기로 결정했기 때문에 예외를 다시 던지는 것은 (예외가 전혀 변경되지 않았다는 것을 의미) 나쁜 생각입니다.
우리가 예외, 예외 메시지 및 처리를 사용하는 이유 중 하나는 무엇이 잘못되었는지 알 수 있고 현명하게 작성된 예외는 버그를 훨씬 빨리 찾아 낼 수 있다는 것입니다.
또한 예외를 처리하는 데 비용이 더 많이 든다는 것을 기억 if하십시오. 따라서 느낌이 들기 때문에 모든 것을 자주 처리해서는 안됩니다. 응용 프로그램의 성능에 영향을 미칩니다.
그러나 오류가 나타난 응용 프로그램 계층을 표시하는 수단으로 예외를 사용하는 것이 좋습니다.
다음과 같은 세미 의사 코드를 고려하십시오.
interface ICache<T, U>
{
T GetValueByKey(U key); // may throw an CacheException
}
class FileCache<T, U> : ICache<T, U>
{
T GetValueByKey(U key)
{
throw new CacheException("Could not retrieve object from FileCache::getvalueByKey. The File could not be opened. Key: " + key);
}
}
class RedisCache<T, U> : ICache<T, U>
{
T GetValueByKey(U key)
{
throw new CacheException("Could not retrieve object from RedisCache::getvalueByKey. Failed connecting to Redis server. Redis server timed out. Key: " + key);
}
}
class CacheableInt
{
ICache<int, int> cache;
ILogger logger;
public CacheableInt(ICache<int, int> cache, ILogger logger)
{
this.cache = cache;
this.logger = logger;
}
public int GetNumber(int key) // may throw service exception
{
int result;
try {
result = this.cache.GetValueByKey(key);
} catch (Exception e) {
this.logger.Error(e);
throw new ServiceException("CacheableInt::GetNumber failed, because the cache layer could not respond to request. Key: " + key);
}
return result;
}
}
class CacheableIntService
{
CacheableInt cacheableInt;
ILogger logger;
CacheableInt(CacheableInt cacheableInt, ILogger logger)
{
this.cacheableInt = cacheableInt;
this.logger = logger;
}
int GetNumberAndReturnCode(int key)
{
int number;
try {
number = this.cacheableInt.GetNumber(key);
} catch (Exception e) {
this.logger.Error(e);
return 500; // error code
}
return 200; // ok code
}
}
누군가가 코드를 호출 GetNumberAndReturnCode하고 500코드를 수신하여 오류를 표시 했다고 가정 해 봅시다 . 그는 지원 부서에 연락하여 로그 파일을 열고 다음을 확인합니다.
ERROR: 12:23:27 - Could not retrieve object from RedisCache::getvalueByKey. Failed connecting to Redis server. Redis server timed out. Key: 28
ERROR: 12:23:27 - CacheableInt::GetNumber failed, because the cache layer could not respond to request. Key: 28
그런 다음 개발자는 프로세스를 중단시킨 소프트웨어 계층을 즉시 알고 문제를 쉽게 식별 할 수 있습니다. 이 경우 Redis 시간 초과가 발생하지 않아야하므로 중요합니다.
다른 사용자가 동일한 메소드를 호출하고 500코드를 수신 할 수도 있지만 로그는 다음을 표시합니다.
INFO: 11:11:11- Could not retrieve object from RedisCache::getvalueByKey. Value does not exist for the key 28.
INFO: 11:11:11- CacheableInt::GetNumber failed, because the cache layer could not find any data for the key 28.
이 경우 지원은 존재하지 않는 ID 값을 요청하여 요청이 유효하지 않다고 사용자에게 간단히 응답 할 수 있습니다.
요약
예외를 처리하는 경우 올바른 방식으로 처리하십시오. 또한 아키텍처 계층에 따라 우선 올바른 데이터 / 메시지를 포함 시키십시오. 따라서 메시지는 발생할 수있는 문제를 식별하는 데 도움이됩니다.