कैसे तेजी से JVM पर त्रुटियों को संभालने के लिए

प्रोग्रामिंग भाषाओं में त्रुटियों को संभालने के विभिन्न तरीके हैं:

• कई भाषाओं के लिए मानक अपवाद (जावा, स्काला और अन्य जेवीएम, अजगर, और कई अन्य)
• स्थिति कोड या ध्वज (गो, मार)
• विभिन्न बीजीय डेटा संरचनाएं, जिनमें से मान सफल परिणाम और त्रुटि विवरण (स्केल, हैसेल और अन्य कार्यात्मक भाषा) दोनों हो सकते हैं

अपवाद बहुत व्यापक रूप से उपयोग किए जाते हैं, दूसरी ओर उन्हें अक्सर धीमा होने के लिए कहा जाता है। लेकिन एक कार्यात्मक दृष्टिकोण के विरोधी अक्सर प्रदर्शन के लिए अपील करते हैं।

हाल ही में, मैं स्काला के साथ काम कर रहा हूं, जहां मैं त्रुटि से निपटने के लिए अपवादों और विभिन्न डेटा प्रकारों का समान रूप से उपयोग कर सकता हूं, इसलिए मुझे आश्चर्य है कि कौन सा दृष्टिकोण अधिक सुविधाजनक और तेज होगा।

हम तुरंत कोड और झंडे का उपयोग करना छोड़ देंगे, क्योंकि यह दृष्टिकोण जेवीएम भाषाओं में स्वीकार नहीं किया जाता है और, मेरी राय में, बहुत त्रुटि-प्रवण है (मैं सजा के लिए माफी चाहता हूं)। इसलिए, हम अपवादों और विभिन्न प्रकार के एडीटी की तुलना करेंगे। इसके अलावा, एडीटी को एक कार्यात्मक शैली में त्रुटि कोड के उपयोग के रूप में माना जा सकता है।

अद्यतन : स्टैक के बिना अपवाद तुलना में जोड़े जाते हैं

प्रतियोगियों

• अच्छे पुराने अपवाद हैं
• स्टैक ट्रेस के बिना अपवाद, स्टैक ट्रेस को भरने के बाद से एक बहुत धीमी कार्रवाई है
• Try[T] = Success(value: T) | Failure(exception: Throwable) Try[T] = Success(value: T) | Failure(exception: Throwable) - समान अपवाद, लेकिन एक कार्यात्मक आवरण में
• Either[String, T] = Left(error: String) | Right(value: T) Either[String, T] = Left(error: String) | Right(value: T) - एक प्रकार जिसमें परिणाम या त्रुटि का विवरण होता है
• ValidatedNec[String, T] = Valid(value: T) | Invalid(errors: List[String]) ValidatedNec[String, T] = Valid(value: T) | Invalid(errors: List[String]) - कैट्स लाइब्रेरी का एक प्रकार, जिसमें त्रुटि के मामले में विभिन्न त्रुटियों के बारे में कई संदेश हो सकते हैं (बहुत List उपयोग वहां नहीं किया जाता है, लेकिन यह महत्वपूर्ण नहीं है)

संक्षेप में, अपवादों की तुलना स्टैक ट्रेस, बिना और एटीडी के साथ की जाती है, लेकिन कई प्रकारों का चयन किया जाता है, क्योंकि स्काला में एक भी दृष्टिकोण नहीं है और कई की तुलना करना दिलचस्प है।

अपवादों के अलावा, स्ट्रिंग का उपयोग त्रुटियों का वर्णन करने के लिए किया जाता है, लेकिन वास्तविक स्थिति में एक ही सफलता के साथ, विभिन्न वर्गों का उपयोग किया जाएगा ( Either[Failure, T] )।

समस्या

त्रुटि से निपटने के परीक्षण के लिए, हम पार्सिंग और डेटा सत्यापन की समस्या लेते हैं:

 case class Person(name: String, age: Int, isMale: Boolean) type Result[T] = Either[String, T] trait PersonParser { def parse(data: Map[String, String]): Result[Person] } 

यानी कच्चे डेटा का Map[String, String] यदि डेटा मान्य नहीं है, तो आपको Person या त्रुटि प्राप्त करने की आवश्यकता है।

फेंक

अपवादों का उपयोग करते हुए माथे के लिए एक समाधान (इसके बाद मैं केवल person फ़ंक्शन देगा, आप पूर्ण कोड को देख सकते हैं:
ThrowParser.scala

  def person(data: Map[String, String]): Person = { val name = string(data.getOrElse("name", null)) val age = integer(data.getOrElse("age", null)) val isMale = boolean(data.getOrElse("isMale", null)) require(name.nonEmpty, "name should not be empty") require(age > 0, "age should be positive") Person(name, age, isMale) } 

यहां string , integer और boolean सरल प्रकार की उपस्थिति और प्रारूप को मान्य करते हैं और रूपांतरण करते हैं।
सामान्य तौर पर, यह काफी सरल और समझ में आता है।

थ्रॉन्स्ट (नो स्टैक ट्रेस)

कोड पिछले मामले की तरह ही है, लेकिन अपवादों का उपयोग स्टैक ट्रेस के बिना किया जाता है जहां संभव हो: ThrowNSTParit.alala

कोशिश

समाधान पहले अपवादों को पकड़ता है और इसके माध्यम से परिणामों के संयोजन की अनुमति देता है (अन्य भाषाओं में लूप के साथ भ्रमित नहीं होने के लिए):
TryParser.scala

  def person(data: Map[String, String]): Try[Person] = for { name <- required(data.get("name")) age <- required(data.get("age")) flatMap integer isMale <- required(data.get("isMale")) flatMap boolean _ <- require(name.nonEmpty, "name should not be empty") _ <- require(age > 0, "age should be positive") } yield Person(name, age, isMale) 

एक नाजुक आंख के लिए थोड़ा अधिक असामान्य है, लेकिन इसके उपयोग के कारण, यह अपवाद के साथ संस्करण के समान है, इसके अलावा, एक क्षेत्र की उपस्थिति का सत्यापन और वांछित प्रकार के पार्सिंग अलग से होते हैं ( flatMap रूप में and then पढ़ा जा सकता है)

भी

त्रुटि प्रकार तय होने के बाद से Result उर्फ के पीछे छिपा हुआ है।
EitherParser.scala

  def person(data: Map[String, String]): Result[Person] = for { name <- required(data.get("name")) age <- required(data.get("age")) flatMap integer isMale <- required(data.get("isMale")) flatMap boolean _ <- require(name.nonEmpty, "name should not be empty") _ <- require(age > 0, "age should be positive") } yield Person(name, age, isMale) 

चूंकि मानक Either जैसे कि Try स्काला में एक मोनाड बनाता है, कोड बिल्कुल समान था, यहां अंतर यह है कि स्ट्रिंग त्रुटि के रूप में यहां दिखाई देती है और अपवाद न्यूनतम रूप से उपयोग किए जाते हैं (केवल एक नंबर को पार्स करते समय त्रुटियों को संभालने के लिए)

मान्य

यहाँ कैट्स लाइब्रेरी का उपयोग पहली चीज़ को प्राप्त करने के लिए किया जाता है, लेकिन जितना संभव हो उतना संभव है (उदाहरण के लिए, यदि कई फ़ील्ड मान्य नहीं थे, तो परिणाम में इन सभी क्षेत्रों के लिए पार्सिंग त्रुटियां होंगी)
ValidatedParser.scala

  def person(data: Map[String, String]): Validated[Person] = { val name: Validated[String] = required(data.get("name")) .ensure(one("name should not be empty"))(_.nonEmpty) val age: Validated[Int] = required(data.get("age")) .andThen(integer) .ensure(one("age should be positive"))(_ > 0) val isMale: Validated[Boolean] = required(data.get("isMale")) .andThen(boolean) (name, age, isMale).mapN(Person) } 

यह कोड अपवादों के साथ मूल संस्करण के समान पहले से कम है, लेकिन अतिरिक्त प्रतिबंधों के सत्यापन को पार्सिंग फ़ील्ड से तलाक नहीं दिया जाता है और हमें अभी भी एक के बजाय कई त्रुटियां मिलती हैं, यह इसके लायक है!

परीक्षण

परीक्षण के लिए, एक डेटा सेट त्रुटियों के एक अलग प्रतिशत के साथ उत्पन्न हुआ था और प्रत्येक तरीके से पार्स किया गया था।

त्रुटियों के सभी प्रतिशत पर परिणाम:

अधिक विस्तार में, त्रुटियों के कम प्रतिशत पर ( एक बड़ा नमूना इस्तेमाल किए जाने के बाद से समय यहां अलग है):

यदि त्रुटियों का कुछ हिस्सा अभी भी स्टैक ट्रेस के साथ अपवाद है (हमारे मामले में, संख्या को पार्स करने में त्रुटि एक अपवाद होगी जिसे हम नियंत्रित नहीं करते हैं), तो निश्चित रूप से "तेज" त्रुटि हैंडलिंग विधियों का प्रदर्शन काफी बिगड़ जाएगा। Validated विशेष रूप से प्रभावित होता है, क्योंकि यह सभी त्रुटियों को एकत्र करता है और परिणामस्वरूप दूसरों की तुलना में धीमा अपवाद प्राप्त करता है:

निष्कर्ष

जैसा कि प्रयोग में दिखाया गया है, स्टैक के निशान वाले अपवाद वास्तव में बहुत धीमे हैं (100% त्रुटियां 50 से अधिक बार Throw और Either बीच का अंतर हैं!), और जब व्यावहारिक रूप से कोई अपवाद नहीं हैं, तो ADT के उपयोग से इसकी कीमत है। हालाँकि, बिना स्टैक ट्रैस के अपवादों का उपयोग करना ADT के रूप में तेज़ (और त्रुटियों के कम प्रतिशत के साथ) है, हालाँकि, यदि ऐसे अपवाद समान मान्यता से परे जाते हैं, तो उनके स्रोत पर नज़र रखना आसान नहीं होगा।

कुल मिलाकर, यदि अपवाद की संभावना 1% से अधिक है, तो स्टैक के बिना अपवाद सबसे तेज़ी से काम करते हैं, Validated या नियमित रूप से Either लगभग उपवास के रूप में हैं। बड़ी संख्या में त्रुटियों के साथ, असफल-तेज़ शब्दार्थ के कारण Either Validated से थोड़ा अधिक तेज़ हो सकता है।

त्रुटि से निपटने के लिए ADT का उपयोग अपवादों पर एक और लाभ प्रदान करता है: त्रुटि की संभावना को स्वयं प्रकार में वायर्ड किया जाता है और इसे याद करना अधिक कठिन होता है, जैसे कि नल के बजाय Option का उपयोग करते समय।