Runtime: أضف TryParse إلى XDocument

تم إنشاؤها على ١٥ يونيو ٢٠١٦ · 3تعليقات · مصدر: dotnet/runtime

مرحبًا ، هذه مشكلة في RFC لطلب دعم لإضافة طريقة bool TryParse(string text, out XDocument document) إلى فئة XDocument .

لقد بحثت في جميع أنحاء الريبو ولكن لا يمكنني العثور على أي شيء ذي صلة ، لذلك إذا كان هذا خداعًا ، فلا تتردد في إغلاقه.

مشكلة:

يحدث أحيانًا أنه يتعين عليك العمل مع ملفات XML التي تأتي من مصادر _ غير موثوق بها ، وعليك التأكد من أن الملف مكون بالفعل بتنسيق XML جيدًا.

توجد حاليًا بعض الطرق غير اللطيفة للتحقق من أن السلسلة عبارة عن تنسيق XML جيد يتضمن معالجة الاستثناءات.

لا تبدو أي من الطرق المقترحة كحل نظيف لمشكلة شائعة جدًا (على الأقل IMO).

يرجى ملاحظة أيضًا أن فئات BCL الأخرى التي تعرض طريقة Parse(string source) عادةً ما تعرض أيضًا bool TryParse(string source, out...) وبالتالي فإن إضافة طريقة TryParse ستجعل فئة XDocument إلى حد ما أكثر اتساقًا مع فئات BCL الأخرى.

اقتراح:

أضف الطريقة التالية

bool TryParse(string text, out XDocument document)

إلى الفصول الدراسية XDocument و XElement

سؤال:

هل نحتاج إلى ميزة التكافؤ مع فئات XmlDocument ؟
في الواقع ، يعرض XmlDocument LoadXml(string xml) لذلك يمكننا إضافة bool TryLoadXml(string xml, out XmlDocument document) لكنني حقًا لا أحب الاسم ، وبالتالي إذا لم يكن تكافؤ الميزات أمرًا ضروريًا ، فأنا أفضل عدم إضافته.

area-System.Xml

مصدر

ilmax

👍2

التعليق الأكثر فائدة

weshaggard ،

بصرف النظر عن الملاءمة ، ستسمح طريقة TryParse للمطور بتخطي النفقات العامة المرتبطة بكتل try / catch وإنشاء مثيل XmlException غير مطلوب حتى أنه قد لا يهتم بأمره.

أنا أيضًا فوجئت جدًا باكتشاف عدم وجود مثل هذه الطريقة. : |

Crono1981 في ٢١ أغسطس ٢٠١٩

👍2

ال 3 كومينتر

لقد راجعنا هذا ولم نفهم تمامًا قيمة إضافة طريقة TryParse في هذه الحالة. في حين أن الاتساق مع أنواع BCL الأخرى مثير للاهتمام إلى حد ما ، إلا أنه مفيد أكثر في تلك الحالات لأنه من المحتمل أن تقوم بتحليل الكثير منها وبالتالي هناك مشكلة في الأداء. في هذه الحالة ، لن يكون الأداء مشكلة حقًا لأن تكلفة الاستثناء ضئيلة مقارنة بتكلفة تحليل مستند XML بأكمله. أيضًا باستخدام طرق التحليل ، ستحصل على XmlException عن الأخطاء والذي يوفر معلومات إضافية توجهك إلى خطأ التحليل الذي لم يكن لديك في حالات TryParse.

بالنسبة للحالات المماثلة ، لا تقدم واجهات برمجة تطبيقات Roslyn طريقة TryParse لتحليل ملف CS إما لأنك تريد عمومًا المزيد من السياق حول أي أخطاء ، ولكن حتى هذا ربما يكون مبالغة في تحليل مستندات XML وهذا هو السبب في أننا نمتلك الأرضية الوسطى للمعلومات الأساسية في XmlException.

نشكرك على المشكلة وكتابتها ولكن لهذه الأسباب لا نعتقد أن هناك قيمة كبيرة في إضافة طريقة TryParse إلى هذه.

weshaggard في ١١ أكتوبر ٢٠١٦

😕3

weshaggard ،

أنا أيضًا فوجئت جدًا باكتشاف عدم وجود مثل هذه الطريقة. : |

Crono1981 في ٢١ أغسطس ٢٠١٩

👍2

بالنسبة لي شخصيًا ، فإن إجابة weshaggard لا معنى لها. Imo all ppl هناك ، باستخدام .NET لمدة تزيد عن نصف عام ، تدرك تمامًا التفسيرات الواردة في الجزء الأول من مشاركة @ weshaggard. عدم التعامل مع الأخطاء وعدم الاهتمام بها بالتفصيل هو ، على الأقل بالنسبة لي خلال العشرين عامًا الماضية ، السبب الرئيسي لاستخدام متغير TryParse () ، إذا كان الفصل يوفر واحدًا.

أعتقد أن الكثير من الأشخاص قد جاءوا إلى هنا في السنوات الـ X الماضية ، بعد النظر إلى منشور Stackoverflow حول هذا الموضوع ، وذهب مثل "أوه. لا يوجد حقًا TryParse () على XDocument. غريب."

لكن مهما يكن.