39

जब आप कक्षा अपवाद (नया अपवाद बनाने के लिए) के साथ कक्षा का विस्तार करते हैं तो आपको serialVersionUID रखने की चेतावनी मिलती है। मुझे पता है कि serialVersionUID सीरियलाइजेशन और deserialization जबकि एक महत्वपूर्ण भूमिका निभाता है, लेकिन जब मेरी अपवाद को क्रमबद्ध करने की जरूरत है? क्या कोई मुझे एक व्यावहारिक मामला दे सकता है जिसमें मैं अपनी कस्टम अपवाद कक्षा को क्रमबद्धता और deserialization चाहते हैं?क्यों मेरे अपवाद वर्ग को क्रमबद्ध करने की आवश्यकता है?

उत्तर

50

ऐसा इसलिए है क्योंकि सभी अपवादों के लिए रूट क्लास, ThrowableSerializable इंटरफ़ेस लागू करता है। डिफ़ॉल्ट रूप से सभी अपवाद serializable हैं और यह एक भाषा डिजाइन निर्णय है क्योंकि लेखकों को किसी भी विशेष विन्यास के बिना तार भर में भेजने के लिए अपवाद चाहते थे।

यदि बेस क्लास धारावाहिक नहीं है, तो आपको रिमोट विधि विफल होने के मामले में वास्तव में गलत होने पर एक कठिन समय होगा क्योंकि आपके द्वारा निर्मित अपवाद प्रकारों पर कोई नियंत्रण नहीं होगा।

11

यदि आपका कस्टम अपवाद किसी वितरित एप्लिकेशन (आरएमआई, स्प्रिंग http-invoker, जो भी हो) में उपयोग किया जाता है और रिमोट क्लाइंट से आने वाली सर्वर विधि से फेंक दिया जा सकता है, तो अपवाद को क्रमबद्ध करना होगा तार पार करने और ग्राहक के पास जाने के लिए।

4

आपके प्रत्येक विकल्प को को परिभाषित करने के लिए प्रत्येक Exception प्रकार को परिभाषित करना है (आईडीई इसे आपके लिए उत्पन्न कर सकता है) या चेतावनी को दबाने के लिए।

आप मेरे पहले के प्रश्न explicit serialVersionUID considered harmful? प्रासंगिक पा सकते हैं।

संबंधित मुद्दे