केवल एक अपवाद को रोकना क्योंकि आपने कैच ब्लॉक का उपयोग करके इसे लॉग इन करने का निर्णय लिया है (जिसका अर्थ है कि अपवाद बिल्कुल नहीं बदला है) एक बुरा विचार है।
हमारे द्वारा अपवादों, अपवाद संदेशों और इसके हैंडलिंग का उपयोग करने का एक कारण यह है कि हम जानते हैं कि क्या गलत हुआ और चतुराई से लिखे गए अपवाद एक बड़े अंतर से बग ढूंढने में तेजी ला सकते हैं।
यह भी याद रखें, अपवादों को संभालने से अधिक संसाधनों की लागत होती है, जैसे कि हमारे पास ऐसा है 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
फिर डेवलपर को तुरंत पता चल जाता है कि सॉफ्टवेयर की किस परत के कारण प्रक्रिया निरस्त हो गई और इस मुद्दे की पहचान करने का एक आसान तरीका है। इस मामले में यह महत्वपूर्ण है, क्योंकि रेडिस टाइमिंग को कभी भी खुश नहीं होना चाहिए।
शायद एक अन्य उपयोगकर्ता उसी विधि को कॉल करेगा, 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.
जिस स्थिति में समर्थन केवल उपयोगकर्ता को जवाब दे सकता है कि अनुरोध अमान्य था क्योंकि वह एक गैर-मौजूद आईडी के लिए एक मूल्य का अनुरोध कर रहा है।
सारांश
यदि आप अपवादों को संभाल रहे हैं, तो उन्हें सही तरीके से संभालना सुनिश्चित करें। यह भी सुनिश्चित करें कि आपके अपवाद में आपकी वास्तुकला परतों का पालन करते हुए, पहले स्थान पर सही डेटा / संदेश शामिल हैं, इसलिए संदेश आपको एक समस्या की पहचान करने में मदद करेंगे जो हो सकती है।