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

لا أرغب في ركوب الدراجة (لا تتردد في تأجيل هذه المحادثة) ، لكن راست ذهب إلى هناك واستقر في النهاية مع عامل postfix ? بدلاً من وظيفة مضمنة ، لزيادة سهولة القراءة.

يستشهد اقتراح gophercon ? في الأفكار المدروسة ويعطي ثلاثة أسباب لتجاهلها: الأول ("عمليات نقل التدفق كقاعدة عامة مصحوبة بالكلمات الرئيسية") والثالث ("يتم تعريف المعالجات بشكل طبيعي أكثر بكلمة رئيسية ، لذا يجب أن تكون عمليات التحقق أيضًا ") لا تنطبق بعد الآن. الثاني هو الأسلوب: يقول أنه حتى لو كان عامل التشغيل postfix يعمل بشكل أفضل للتسلسل ، فإنه لا يزال بإمكانه قراءة الأسوأ في بعض الحالات مثل:

check io.Copy(w, check newReader(foo))

بدلا من:

io.Copy(w, newReader(foo)?)?

لكن الآن سيكون لدينا:

try(io.Copy(w, try(newReader(foo))))

الذي أعتقد أنه من الواضح أنه الأسوأ من الثلاثة ، لأنه لم يعد واضحًا بعد الآن ما هي الوظيفة الرئيسية التي يتم استدعاؤها.

لذا فإن جوهر تعليقي هو أن الأسباب الثلاثة المذكورة في اقتراح gophercon لعدم استخدام ? لا تنطبق على عرض try هذا ؛ ? موجز ، سهل القراءة ، لا يحجب بنية البيان (مع تسلسل استدعاءات وظيفته الداخلية) ، وهو قابل للتسلسل. إنه يزيل المزيد من الفوضى من العرض ، بينما لا يحجب تدفق التحكم أكثر مما يفعله بالفعل try() المقترح.

للتوضيح:

هل

func f() (n int, err error) {
  n = 7
  try(errors.New("x"))
  // ...
}

إرجاع (0، "x") أو (7، "x")؟ كنت أفترض الأخير.

هل يجب تسمية الخطأ الذي تم إرجاعه في حالة عدم وجود زخرفة أو معالجة (كما هو الحال في وظيفة المساعد الداخلي)؟ لا أفترض.

المثال الخاص بك يعيد 7, errors.New("x") . يجب أن يكون هذا واضحًا في المستند الكامل الذي سيتم إرساله قريبًا (https://golang.org/cl/180557).

لا يلزم تسمية معلمة نتيجة الخطأ لاستخدام try . تحتاج فقط إلى تسميتها إذا كانت الوظيفة تحتاج إلى الرجوع إليها في دالة مؤجلة أو في مكان آخر.

أنا غير سعيد حقًا بوظيفة مدمجة تؤثر على تدفق التحكم في المتصل. أقدر استحالة إضافة كلمات رئيسية جديدة في Go 1 ، ولكن حل هذه المشكلة باستخدام الوظائف المدمجة السحرية يبدو خطأً بالنسبة لي. لا يؤدي تظليل العناصر المضمنة الأخرى إلى نتائج غير متوقعة مثل تغيير تدفق التحكم.

لا أحب الطريقة التي تبدو بها postfix ? ، لكنني أعتقد أنها لا تزال تتفوق try() .

تحرير: حسنًا ، لقد نسيت تمامًا أن الذعر موجود وليس كلمة رئيسية.

الاقتراح المفصل هنا (تحسينات التنسيق المعلقة ، ستأتي قريبًا) ونأمل أن يجيب على الكثير من الأسئلة.

dominikh يناقش الاقتراح التفصيلي هذا الأمر بالتفصيل ، ولكن يرجى ملاحظة أن panic و recover هما عنصران مدمجان يؤثران على تدفق التحكم أيضًا.

توضيح / اقتراح واحد للتحسين:

if the last argument supplied to try, of type error, is not nil, the enclosing function’s error result variable (...) is set to that non-nil error value before the enclosing function returns

هل يمكن أن يقول هذا بدلاً من ذلك is set to that non-nil error value and the enclosing function returns ؟ (ق / قبل / و)

في القراءة الأولى ، بدا أن before the enclosing function returns سيحدد قيمة الخطأ _ في بعض الأحيان_ في وقت ما في المستقبل قبل إرجاع الدالة مباشرةً - ربما في سطر لاحق. التفسير الصحيح هو أن المحاولة قد تؤدي إلى عودة الوظيفة الحالية. يعد هذا سلوكًا مفاجئًا للغة الحالية ، لذا سيكون النص الأكثر وضوحًا موضع ترحيب.

أعتقد أن هذا مجرد سكر ، وقام عدد قليل من المعارضين الصاخبين بمضايقة جولانغ بشأن الاستخدام المتكرر لكتابة if err != nil ... وأخذها شخص ما على محمل الجد. لا أعتقد أنها مشكلة. الأشياء الوحيدة المفقودة هي هاتان المادتان المضمنتان:

https://github.com/purpleidea/mgmt/blob/a235b760dc3047a0d66bb0b9d63c25bc746ed274/util/errwrap/errwrap.go#L26

لست متأكدًا من سبب كتابة أي شخص لوظيفة مثل هذه ولكن ما هو الناتج المتصور

try(foobar())

إذا أرجع $ foobar (error, error)

لقد تراجعت عن مخاوفي السابقة بشأن تدفق التحكم ولم أعد أقترح استخدام ? . أعتذر عن الرد السريع (على الرغم من أنني أود أن أشير إلى أن هذا لم يكن ليحدث لو تم تقديم المشكلة بعد _ كان الاقتراح الكامل متاحًا).

لا أوافق على ضرورة المعالجة المبسطة للخطأ ، لكنني متأكد من أنها معركة خاسرة. يبدو أن try كما هو موضح في الاقتراح هو أقل الطرق سوءًا للقيام بذلك.

webermaster تعتبر النتيجة error الأخيرة فقط خاصة للتعبير الذي تم تمريره إلى try ، كما هو موضح في مستند الاقتراح.

مثل dominikh ، أنا أيضًا لا أتفق مع ضرورة معالجة الأخطاء بشكل مبسط.

إنه ينقل التعقيد الرأسي إلى التعقيد الأفقي الذي نادرًا ما يكون فكرة جيدة.

إذا كان لا بد لي من الاختيار بين تبسيط مقترحات معالجة الأخطاء ، فسيكون هذا هو اقتراحي المفضل.

سيكون من المفيد أن يكون هذا مصحوبًا (في مرحلة ما من القبول) بأداة لتحويل كود Go لاستخدام try في بعض المجموعات الفرعية من وظائف إرجاع الخطأ حيث يمكن إجراء مثل هذا التحويل بسهولة بدون تغيير الدلالات. ثلاث فوائد تخطر ببالي:

• عند تقييم هذا الاقتراح ، سيسمح للأشخاص بالتعرف بسرعة على كيفية استخدام try في قاعدة الكود الخاصة بهم.
• إذا try في إصدار مستقبلي من Go ، فمن المحتمل أن يرغب الناس في تغيير الكود الخاص بهم للاستفادة منه. إن امتلاك أداة لأتمتة الحالات السهلة سيساعد كثيرًا.
• إن وجود طريقة لتحويل قاعدة بيانات كبيرة بسرعة لاستخدام try سيجعل من السهل فحص تأثيرات التنفيذ على نطاق واسع. (على سبيل المثال ، الدقة والأداء وحجم الكود.) قد يكون التنفيذ بسيطًا بما يكفي لجعل هذا اعتبارًا لا يُذكر.

أود فقط أن أعبر عن أنني أعتقد أن الإنقاذ الفعلي لوظيفة الاستدعاء من try(foo()) يزيل منا الإشارة المرئية التي قد يتغير تدفق الوظيفة اعتمادًا على النتيجة.

أشعر أنه يمكنني العمل مع try نظرًا لما يكفي من التعود ، لكنني أشعر أيضًا أننا سنحتاج إلى دعم IDE إضافي (أو بعضه) لتسليط الضوء على try للتعرف بكفاءة على التدفق الضمني في مراجعات الكود / جلسات التصحيح

أكثر ما يقلقني هو الحاجة إلى تسمية قيم الإرجاع فقط حتى يكون بيان التأجيل سعيدًا.

أعتقد أن مشكلة معالجة الخطأ الشاملة التي يشكو المجتمع منها هي مزيج من النموذج المعياري if err != nil وإضافة سياق إلى الأخطاء. تنص الأسئلة الشائعة بوضوح على أن المشكلة الأخيرة تم استبعادها عن قصد كمشكلة منفصلة ، لكنني أشعر أن هذا سيصبح حلاً غير مكتمل ، لكنني سأكون على استعداد لمنحه فرصة بعد التفكير في هذين الأمرين:

1. قم بتعريف err في بداية الوظيفة.
   هل هذا فعال؟ أذكر المشكلات المتعلقة بالنتائج المؤجلة وغير المسماة. إذا لم يكن الأمر كذلك ، فإن الاقتراح يحتاج إلى النظر في ذلك.

func sample() (string, error) {
  var err error
  defer fmt.HandleErrorf(&err, "whatever")
  s := try(f())
  return s, nil
}

1. قم بتعيين القيم كما فعلنا في الماضي ، ولكن استخدم الدالة المساعدة wrapf التي تحتوي على if err != nil boilerplate.

func sample() (string, error) {
  s, err := f()
  try(wrapf(err, "whatever"))
  return s, nil
}
func wrapf(err error, format string, ...v interface{}) error {
  if err != nil {
    // err = wrapped error
  }
  return err
}

إذا نجح أي منهما ، يمكنني التعامل معه.

func sample() (string, error) {
  var err error
  defer fmt.HandleErrorf(&err, "whatever")
  s := try(f())
  return s, nil
}

هذا لن يعمل. سيقوم المؤجل بتحديث المتغير المحلي err ، والذي لا علاقة له بقيمة الإرجاع.

func sample() (string, error) {
  s, err := f()
  try(wrapf(err, "whatever"))
  return s, nil
}
func wrapf(err error, format string, ...v interface{}) error {
  if err != nil {
    // err = wrapped error
  }
  return err
}

التي يجب أن تعمل. ومع ذلك ، فإنه سوف يستدعي wrapf حتى عند وجود خطأ لا شيء.
سيعمل هذا أيضًا (يستمر في) العمل ، وستكون IMO أكثر وضوحًا:

func sample() (string, error) {
  s, err := f()
  if err != nil {
      return "", wrap(err)
  }
  return s, nil
}

لن يجعلك أحد تستخدم try .

لست متأكدًا من سبب كتابة أي شخص لوظيفة مثل هذه ولكن ما هو الناتج المتصور

try(foobar())

إذا أرجع $ foobar (error, error)

لماذا تقوم بإرجاع أكثر من خطأ من دالة؟ إذا كنت تقوم بإرجاع أكثر من خطأ واحد من الوظيفة ، فربما يجب تقسيم الوظيفة إلى جزأين منفصلين في المقام الأول ، كل منهما يعرض خطأ واحدًا فقط.

هل يمكنك التفصيل بمثال؟

cespare : يجب أن يكون بإمكان أي شخص كتابة go fix يعيد كتابة الكود الحالي المناسب لـ try بحيث يستخدم try . قد يكون من المفيد التعرف على كيفية تبسيط الكود الموجود. لا نتوقع أي تغييرات كبيرة في حجم الشفرة أو أدائها ، نظرًا لأن try هو مجرد سكر نحوي ، يستبدل النمط الشائع بقطعة أقصر من شفرة المصدر تنتج بشكل أساسي نفس كود الإخراج. لاحظ أيضًا أن الكود الذي يستخدم try سيكون ملزمًا باستخدام إصدار Go وهو على الأقل الإصدار الذي تم تقديم try فيه.

lestrrat : وافق على أنه يجب على المرء أن يتعلم أن try يمكن أن يغير تدفق التحكم. نشك في أن IDE يمكن أن يسلط الضوء على ذلك بسهولة كافية.

@ Goodwine : كما أشار @ randall77 بالفعل ، فإن اقتراحك الأول لن ينجح. أحد الخيارات التي فكرنا فيها (ولكن لم تتم مناقشتها في المستند) هو إمكانية وجود متغير محدد مسبقًا يشير إلى النتيجة error (إذا كان أحدهم موجودًا في المقام الأول). سيؤدي ذلك إلى التخلص من الحاجة إلى تسمية تلك النتيجة بحيث يمكن استخدامها في defer . لكن هذا سيكون سحرًا أكثر ؛ لا يبدو له ما يبرره. مشكلة تسمية النتيجة المرتجعة هي مشكلة تجميلية بشكل أساسي ، وأهم ما يكون في واجهات برمجة التطبيقات التي يتم إنشاؤها تلقائيًا والتي يقدمها go doc والأصدقاء. سيكون من السهل معالجة هذا الأمر في تلك الأدوات (انظر أيضًا الأسئلة الشائعة الخاصة بمستند التصميم التفصيلي حول هذا الموضوع).

nictuku : فيما يتعلق باقتراحك للتوضيح (ق / قبل / و /): أعتقد أن الكود مباشرة قبل الفقرة التي تشير إليها يوضح ما يحدث بالضبط ، لكني أرى وجهة نظرك ، قبل / و / قد اجعل النثر أكثر وضوحا. سأقوم بالتغيير.

انظر CL 180637 .

أنا حقا أحب هذا الاقتراح. ومع ذلك ، لدي نقد واحد. تم دائمًا تمييز نقطة الخروج من الوظائف في Go بـ return . تعتبر حالات الذعر أيضًا نقاط خروج ، ولكنها أخطاء فادحة لا يُقصد عادةً مواجهتها أبدًا.

قد يؤدي إنشاء نقطة خروج لدالة ليست return ، ويُقصد بها أن تكون شائعة ، إلى رمز أقل قابلية للقراءة. لقد سمعت عن هذا في حديث ومن الصعب أن أفهم جمال كيفية بناء هذا الكود:

func CopyFile(src, dst string) error {
    r, err := os.Open(src)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    defer r.Close()

    w, err := os.Create(dst)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if _, err := io.Copy(w, r); err != nil {
        w.Close()
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if err := w.Close(); err != nil {
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
}

قد يبدو هذا الرمز وكأنه فوضى كبيرة ، وكان _ يعني _ من خلال مسودة معالجة الخطأ ، لكن دعنا نقارنه بالشيء نفسه بـ try .

func CopyFile(src, dst string) error {
    defer func() {
        err = fmt.Errorf("copy %s %s: %v", src, dst, err)
    }()
    r, err := try(os.Open(src))
    defer r.Close()

    w, err := try(os.Create(dst))

    defer w.Close()
    defer os.Remove(dst)
    try(io.Copy(w, r))
    try(w.Close())

    return nil
}

قد تنظر إلى هذا للوهلة الأولى وتعتقد أنه يبدو أفضل ، لأنه يوجد عدد أقل بكثير من التعليمات البرمجية المتكررة. ومع ذلك ، كان من السهل جدًا تحديد جميع النقاط التي أعادتها الوظيفة في المثال الأول. تم وضع مسافة بادئة لها جميعًا وبدأت بـ return ، متبوعة بمسافة. هذا بسبب حقيقة أن جميع المرتجعات الشرطية _يجب_ أن تكون داخل الكتل الشرطية ، وبالتالي يتم وضع مسافة بادئة لها بواسطة معايير gofmt . return هو أيضًا ، كما ذكر سابقًا ، الطريقة الوحيدة لترك دالة دون القول بحدوث خطأ فادح. في المثال الثاني ، لا يوجد سوى return واحد ، لذلك يبدو أن الشيء الوحيد الذي يجب أن تقوم الوظيفة _ever_ بإرجاعه هو nil . من السهل رؤية مكالمتين الأخيرتين try ، لكن الأولين يكونان أصعب قليلاً ، وسيكونان أكثر صعوبة إذا تم تداخلهما في مكان ما ، أي شيء مثل proc := try(os.FindProcess(try(strconv.Atoi(os.Args[1])))) .

يبدو أن العودة من الوظيفة كان أمرًا "مقدسًا" ، ولهذا السبب أعتقد شخصيًا أن جميع نقاط الخروج للوظيفة يجب تمييزها بـ return .

شخص ما نفذ هذا بالفعل منذ 5 سنوات. إذا كنت مهتمًا ، يمكنك ذلك
جرب هذه الميزة

https://news.ycombinator.com/item؟id=20101417

لقد نفذت try () في Go منذ خمس سنوات باستخدام معالج أولي AST واستخدمته في مشاريع حقيقية ، لقد كان رائعًا: https://github.com/lunixbochs/og

فيما يلي بعض الأمثلة على استخدامه في وظائف التحقق من الأخطاء الثقيلة: https://github.com/lunixbochs/poxd/blob/master/tls.go#L13

أنا أقدر الجهد المبذول في هذا. أعتقد أنه أكثر الحلول التي رأيتها حتى الآن. لكنني أعتقد أنه يقدم مجموعة من الأعمال عند تصحيح الأخطاء. محاولة فك التفاف وإضافة كتلة if في كل مرة أقوم فيها بتصحيحها وإعادة تغليفها عند الانتهاء هو أمر ممل. ولدي أيضًا بعض الانزعاج بشأن متغير الخطأ السحري الذي أحتاج إلى مراعاته. لم يزعجني التحقق الصريح من الخطأ مطلقًا ، لذا ربما أكون الشخص الخطأ الذي أسأله. لقد أذهلني دائمًا أنه "جاهز للتصحيح".

تضمين التغريدة
مشكلتي في استخدامك المقترح لـ "تأجيل" كطريقة للتعامل مع التفاف الخطأ هو أن السلوك من المقتطف الذي عرضته (المكرر أدناه) ليس شائعًا جدًا في AFAICT ، ولأنه نادر جدًا ، يمكنني تخيل الناس يكتبون هذا التفكير أنه يعمل عندما لا يحدث ذلك.

مثل .. لن يعرف المبتدئ هذا ، إذا كان لديهم خطأ بسبب هذا فلن يذهبوا "بالطبع ، أنا بحاجة إلى عودة محددة" ، فسيصابون بالتوتر لأنه يجب أن يعمل وهو لا.

var err error
defer fmt.HandleErrorf(err);

try هو بالفعل ساحر للغاية ، لذا يمكنك أيضًا المضي قدمًا وإضافة قيمة الخطأ الضمني هذه. فكر في المبتدئين ، وليس أولئك الذين يعرفون كل الفروق الدقيقة في Go. إذا لم يكن الأمر واضحًا بما فيه الكفاية ، فلا أعتقد أنه الحل الصحيح.

أو ... لا تقترح استخدام تأجيل مثل هذا ، جرب طريقة أخرى أكثر أمانًا ولكن لا تزال قابلة للقراءة.

deanveloper صحيح أن هذا الاقتراح (وفي هذا الصدد ، أي اقتراح يحاول محاولة نفس الشيء) سيزيل عبارات return المرئية بوضوح من الكود المصدري - وهذا هو بيت القصيد من الاقتراح بعد كل شيء ، أليس كذلك؟ لإزالة الصيغة المعيارية لكشوفات if و returns فكلها متطابقة. إذا كنت تريد الاحتفاظ بـ return ، فلا تستخدم try .

لقد اعتدنا على التعرف فورًا على كشوفات الحساب return (و panic ) لأن هذه هي الطريقة التي يتم بها التعبير عن هذا النوع من تدفق التحكم في Go (والعديد من اللغات الأخرى). يبدو أنه ليس بعيد المنال أننا سنتعرف أيضًا على try كتغيير تدفق التحكم بعد أن يعتاد البعض عليه ، تمامًا كما نفعل مقابل return . ليس لدي شك في أن دعم IDE الجيد سيساعد في هذا أيضًا.

لدي شاغلان:

• لقد كانت عمليات الإرجاع المسماة مربكة للغاية ، وهذا يشجعهم على استخدام حالة استخدام جديدة ومهمة
• سيؤدي هذا إلى تثبيط إضافة سياق إلى الأخطاء

من واقع خبرتي ، تعد إضافة السياق إلى الأخطاء فورًا بعد كل موقع اتصال أمرًا بالغ الأهمية للحصول على رمز يمكن تصحيحه بسهولة. وقد تسببت عمليات العودة المسماة في حدوث ارتباك لكل مطور Go أعرفه تقريبًا في مرحلة ما.

مصدر القلق الأسلوبي البسيط هو أنه من المؤسف عدد سطور التعليمات البرمجية التي سيتم تغليفها الآن بـ try(actualThing()) . يمكنني تخيل رؤية معظم السطور في قاعدة بيانات ملفوفة بـ try() . هذا شعور مؤسف.

أعتقد أنه سيتم التعامل مع هذه المخاوف من خلال تعديل:

a, b, err := myFunc()
check(err, "calling myFunc on %v and %v", a, b)

سيتصرف check() مثل try() ، لكنه سيتخلى عن سلوك تمرير قيم إرجاع الدالة بشكل عام ، وبدلاً من ذلك سيوفر القدرة على إضافة سياق. لا يزال من شأنه أن يؤدي إلى العودة.

سيحتفظ هذا بالعديد من مزايا try() :

• إنه مدمج
• إنه يتبع WRT لتدفق التحكم الحالي للتأجيل
• يتماشى مع الممارسة الحالية لإضافة سياق إلى الأخطاء بشكل جيد
• يتماشى مع العروض والمكتبات الحالية لتغليف الأخطاء ، مثل errors.Wrap(err, "context message")
• ينتج عنه موقع اتصال نظيف: لا توجد لغة معيارية في السطر a, b, err := myFunc()
• لا يزال وصف الأخطاء باستخدام defer fmt.HandleError(&err, "msg") ممكنًا ، ولكن لا داعي للتشجيع.
• التوقيع check أبسط قليلاً ، لأنه لا يحتاج إلى إرجاع عدد عشوائي من الوسيطات من الوظيفة التي يتم تغليفها.

@ s4n-gt شكرا لهذا الارتباط. لم أكن على علم به.

Goodwine نقطة مأخوذة. تمت مناقشة سبب عدم تقديم المزيد من الدعم المباشر لمعالجة الأخطاء في مستند التصميم بالتفصيل. ومن الحقائق أيضًا أنه على مدار عام أو نحو ذلك (منذ أن نُشرت مسودة التصميمات في Gophercon العام الماضي) لم يتم التوصل إلى حل مُرضٍ لمعالجة الأخطاء الصريحة. وهذا هو سبب ترك هذا الاقتراح لهذا الأمر عن قصد (وبدلاً من ذلك يقترح استخدام defer ). ولا يزال هذا الاقتراح يترك الباب مفتوحًا للتحسينات المستقبلية في هذا الصدد.

يذكر الاقتراح تغيير اختبار الحزمة للسماح للاختبارات والمعايير بإرجاع خطأ. على الرغم من أنه لن يكون "تغييرًا متواضعًا في المكتبة" ، إلا أنه يمكننا التفكير في قبول func main() error أيضًا. سيجعل كتابة نصوص صغيرة أجمل بكثير. الدلالات ستكون معادلة لـ:

func main() {
  if err := newmain(); err != nil {
    println(err.Error())
    os.Exit(1)
  }
}

نقد أخير. ليس في الحقيقة انتقادًا للاقتراح نفسه ، ولكن بدلاً من ذلك نقدًا لاستجابة مشتركة للحجة المضادة "وظيفة التحكم في التدفق".

الرد على "لا أحب أن تقوم الوظيفة بالتحكم في التدفق" هو ​​أن " panic يتحكم أيضًا في تدفق البرنامج!". ومع ذلك ، هناك بعض الأسباب التي تجعل من المقبول أن يقوم panic بالقيام بذلك والتي لا تنطبق على try .

1. panic ودود للمبرمجين المبتدئين لأن ما يفعله بديهي ، ويستمر في فك المكدس. لا يجب على المرء حتى البحث عن كيفية عمل panic لفهم ما يفعله. لا يحتاج المبرمجون المبتدئون إلى القلق بشأن recover ، لأن المبتدئين لا يبنون عادة آليات التعافي من الذعر ، خاصة وأنهم دائمًا ما يكونون أقل تفضيلًا من مجرد تجنب الذعر في المقام الأول.

2. panic اسم يسهل رؤيته. إنه يجلب القلق ، ويحتاج إلى ذلك. إذا رأى أحدهم panic في قاعدة بيانات ، يجب أن يفكر على الفور في كيفية تجنب الذعر ، حتى لو كان تافهًا.

3. بعيدًا عن النقطة الأخيرة ، لا يمكن تضمين panic في مكالمة ، مما يجعل رؤيتها أسهل.

لا بأس في أن يتحكم الذعر في تدفق البرنامج لأنه من السهل للغاية اكتشافه ، كما أنه أمر بديهي فيما يفعله.

لا تحقق الوظيفة try أيًا من هذه النقاط.

1. لا يمكن لأحد أن يخمن ما يفعله try دون البحث عن الوثائق الخاصة به. تستخدم العديد من اللغات الكلمة الأساسية بطرق مختلفة ، مما يجعل من الصعب فهم ما تعنيه في Go.

2. try لا يلفت انتباهي ، خاصة عندما تكون وظيفة. _ على وجه الخصوص_ عندما يؤدي إبراز بناء الجملة إلى إبرازها كوظيفة. _ESPECIALLY_ بعد التطوير بلغة مثل Java ، حيث يُنظر إلى try على أنه نموذج معياري غير ضروري (بسبب الاستثناءات المحددة).

3. يمكن استخدام try في وسيطة لاستدعاء دالة ، وفقًا لمثالي في تعليقي السابق proc := try(os.FindProcess(try(strconv.Atoi(os.Args[1])))) . هذا يجعل من الصعب اكتشافها.

تتجاهل عيني وظائف try ، حتى عندما أبحث عنها على وجه التحديد. ستراهم عيناي ، لكني انتقل فورًا إلى المكالمات os.FindProcess أو strconv.Atoi . try هو إرجاع مشروط. يتم تعليق كل من تدفق التحكم والعودة على قواعد في Go. يتم وضع مسافة بادئة لكل تدفق التحكم داخل دالة ، وتبدأ جميع المرتجعات بـ return . إن المزج بين هذين المفهومين معًا في استدعاء دالة سهل الفقدان يبدو قليلاً.

هذا التعليق والأخير هو انتقاداتي الحقيقية الوحيدة للفكرة. أعتقد أنني قد أعتبر أنني لا أحب هذا الاقتراح ، لكنني ما زلت أعتقد أنه فوز شامل لـ Go. لا يزال هذا الحل يشبه Go أكثر من الحلول الأخرى. إذا تمت إضافة هذا ، فسأكون سعيدًا ، ومع ذلك أعتقد أنه لا يزال من الممكن تحسينه ، لست متأكدًا من كيفية القيام بذلك.

تضمين التغريدة كما هو مكتوب ، فإنه ينقل تنسيق fmt من حزمة إلى اللغة نفسها ، مما يفتح علبة من الديدان.

كما هو مكتوب ، فإنه ينقل تنسيق fmt من حزمة إلى اللغة نفسها ، مما يفتح علبة من الديدان.

نقطة جيدة. مثال أبسط:

a, b, err := myFunc()
check(err, "calling myFunc")

buchanae لقد فكرنا في جعل معالجة الخطأ الصريح أكثر ارتباطًا بشكل مباشر بـ try - يرجى الاطلاع على مستند التصميم التفصيلي ، وتحديدًا القسم الخاص بتكرارات التصميم. اقتراحك المحدد لـ check سيسمح فقط بزيادة الأخطاء من خلال شيء مثل fmt.Errorf مثل API (كجزء من check ) ، إذا فهمت بشكل صحيح. بشكل عام ، قد يرغب الأشخاص في القيام بكل أنواع الأشياء التي تحتوي على أخطاء ، وليس فقط إنشاء واحدة جديدة تشير إلى الشيء الأصلي عبر سلسلة الخطأ الخاصة به.

مرة أخرى ، لا يحاول هذا الاقتراح حل جميع حالات معالجة الأخطاء. أظن أنه في معظم الحالات يكون try منطقيًا للشفرة التي تبدو الآن بشكل أساسي كما يلي:

a, b, c, ... err := try(someFunctionCall())
if err != nil {
   return ..., err
}

هناك عدد هائل من التعليمات البرمجية التي تبدو مثل هذا. وليس كل جزء من الكود يبدو بهذا الشكل يحتاج إلى مزيد من معالجة الأخطاء. وحيث يكون defer غير صحيح ، لا يزال بإمكان المرء استخدام كشف حساب if .

أنا لا أتبع هذا الخط:

defer fmt.HandleErrorf(&err, “foobar”)

يسقط الخطأ الداخلي على الأرض ، وهو أمر غير معتاد. هل من المفترض أن يتم استخدام شيء مثل هذا؟

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

الازدواجية في الخطأ هي تلعثم بعض الشيء. هذا لا ينطبق بشكل مباشر على الاقتراح ، مجرد تعليق جانبي حول المستند.

أشارك القلقين اللذين أثارهماbuchanae ، re: الإرجاع المسماة والأخطاء السياقية.

أجد أن الاسم يعود مزعجًا بعض الشيء كما هو ؛ أعتقد أنها مفيدة حقًا فقط كتوثيق. الاعتماد عليهم أكثر هو مصدر قلق. آسف لكوني غامضة جدا ، رغم ذلك. سأفكر في هذا أكثر وأقدم بعض الأفكار الملموسة.

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

أعتقد أن try كما هو مقترح يجعل بعض الكود أجمل بشكل ملحوظ. هذه وظيفة اخترتها بشكل عشوائي من قاعدة رمز مشروعي الحالي ، مع تغيير بعض الأسماء. إنني معجب بشكل خاص بكيفية عمل try عند التعيين لحقول الهيكل. (هذا على افتراض أن قراءتي للاقتراح صحيحة ، وأن هذا يعمل؟)

الكود الحالي:

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        err := dbfile.RunMigrations(db, dbMigrations)
        if err != nil {
                return nil, err
        }
        t := &Thing{
                thingy: thingy,
        }
        t.scanner, err = newScanner(thingy, db, client)
        if err != nil {
                return nil, err
        }
        t.initOtherThing()
        return t, nil
}

بـ try :

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        try(dbfile.RunMigrations(db, dbMigrations))
        t := &Thing{
                thingy:  thingy,
                scanner: try(newScanner(thingy, db, client)),
        }
        t.initOtherThing()
        return t, nil
}

لا يوجد فقدان في قابلية القراءة ، باستثناء أنه من غير الواضح أن newScanner قد يفشل. ولكن في عالم به try Go ، سيكون المبرمجون أكثر حساسية لوجودها.

josharian بخصوص main إرجاع error : يبدو لي أن وظيفتك المساعدة الصغيرة هي كل ما تحتاجه للحصول على نفس التأثير. لست متأكدًا من أن تغيير توقيع main له ما يبرره.

فيما يتعلق بمثال "foobar": إنه مجرد مثال سيء. ربما يجب أن أغيرها. شكرا لإحضاره.

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

في الواقع ، هذا لا يمكن أن يكون صحيحًا ، لأنه سيتم تقييم err مبكرًا جدًا. هناك طريقتان للتغلب على هذا ، لكن أيا منها ليس نظيفًا مثل المقود الأصلي (أعتقد أنه معيب). أعتقد أنه سيكون من الجيد أن يكون لديك مثال عملي أكثر واقعية أو مثالين للدالة المساعدة.

تحرير: خطأ التقييم المبكر هذا موجود في أحد الأمثلة
بالقرب من نهاية المستند:

defer fmt.HandleErrorf(&err, "copy %s %s: %v", src, dst, err)

adg نعم ، يمكن استخدام try أثناء استخدامه في المثال الخاص بك. اسمحوا لي أن تعليقاتكم إعادة: المسماة العودة تقف كما هي.

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

try لا يحاول التعامل مع كل أنواع الأشياء التي يريد الناس القيام بها مع الأخطاء ، فقط تلك الأشياء التي يمكننا إيجاد طريقة عملية لجعلها أبسط بشكل ملحوظ. أعتقد أن مثال check يسير على نفس الخط.

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

ولكن ، ربما ستضيف المقترحات الأخرى تتبعات مكدس لجميع الأخطاء؟ لقد فقدت المسار.

في المثال الذي قدمتهadg ، هناك نوعان من الإخفاقات المحتملة ولكن لا يوجد سياق. إذا لم يقدم newScanner و RunMigrations هم أنفسهم الرسائل التي تدل على الخطأ الذي حدث ، فأنت تترك التخمين.

في المثال الذي قدمتهadg ، هناك نوعان من الإخفاقات المحتملة ولكن لا يوجد سياق. إذا لم يقدم كل من newScanner و RunMigrations الرسائل التي تدل على الخطأ الذي حدث فيه أحد ، فأنت تترك التخمين.

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

أشاركك القلق كـ deanveloper وآخرين من أنه قد يجعل تصحيح الأخطاء أكثر صعوبة. صحيح أنه يمكننا اختيار عدم استخدامه ، لكن أنماط تبعيات الطرف الثالث ليست تحت سيطرتنا.
إذا كانت النقطة الأساسية أقل تكرارًا هي if err := ... { return err } ، أتساءل عما إذا كانت "العودة المشروطة" كافية ، مثل https://github.com/golang/go/issues/27794 المقترحة.

        return nil, err if f, err := os.Open(...)
        return nil, err if _, err := os.Write(...)

أعتقد أن ? سيكون أفضل من try ، كما أن الاضطرار دائمًا إلى مطاردة defer للخطأ سيكون أمرًا صعبًا أيضًا.

يؤدي هذا أيضًا إلى إغلاق البوابات لوجود استثناءات باستخدام try/catch إلى الأبد.

يؤدي هذا أيضًا إلى إغلاق البوابات لوجود استثناءات باستخدام try / catch إلى الأبد.

أنا بخير مع هذا.

أتفق مع بعض المخاوف التي أثيرت أعلاه فيما يتعلق بإضافة سياق إلى الخطأ. أحاول ببطء التحول من مجرد إرجاع خطأ إلى تزيينه دائمًا بسياق ثم إعادته. مع هذا الاقتراح ، سأضطر إلى تغيير وظيفتي تمامًا لاستخدام معلمات الإرجاع المسماة (والتي أشعر أنها غريبة لأنني بالكاد استخدم عوائد عارية).

كما يقول griesemer :

مرة أخرى ، لا يحاول هذا الاقتراح حل جميع حالات معالجة الأخطاء. أظن أن المحاولة في معظم الحالات منطقية بالنسبة إلى الكود الذي يبدو الآن بشكل أساسي كالتالي:
أ ، ب ، ج ، ... يخطئ: = حاول (someFunctionCall ())
إذا أخطأت! = لا شيء {
العودة ... ، يخطئ
}
هناك عدد هائل من التعليمات البرمجية التي تبدو مثل هذا. وليس كل جزء من الكود يبدو بهذا الشكل يحتاج إلى مزيد من معالجة الأخطاء. وحيثما يكون التأجيل غير صحيح ، لا يزال بإمكان المرء استخدام عبارة if.

نعم ، ولكن ليس جيدًا ، فالشفرة الاصطلاحية تغلف / تزين أخطائها دائمًا؟ أعتقد أن هذا هو السبب في أننا نقدم آليات معالجة الأخطاء المحسّنة لإضافة أخطاء السياق / الالتفاف في stdlib. كما أرى ، يبدو أن هذا الاقتراح ينظر فقط في حالة الاستخدام الأساسية.

علاوة على ذلك ، لا يعالج هذا الاقتراح سوى حالة التفاف / تزيين عدة مواقع إرجاع خطأ محتملة في مكان واحد ، باستخدام معلمات مسماة مع استدعاء مؤجل.

لكنها لا تفعل أي شيء للحالة عندما يحتاج المرء إلى إضافة سياقات مختلفة لأخطاء مختلفة في وظيفة واحدة. على سبيل المثال ، من الضروري جدًا تزيين أخطاء قاعدة البيانات للحصول على مزيد من المعلومات حول المكان الذي أتوا منه (بافتراض عدم وجود آثار مكدس)

هذا مثال على رمز حقيقي لدي -

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    if err != nil {
        return err
    }
    var res int64
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    if err != nil {
        tx.Rollback()
        return fmt.Errorf("insert table: %w", err)
    }

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    if err != nil {
        tx.Rollback()
        return fmt.Errorf("insert table2: %w", err)
    }
    return tx.Commit()
}

حسب العرض:

إذا كان هناك رغبة في زيادة أو التفاف الخطأ ، فهناك طريقتان: التمسك بعبارة if try-and-true ، أو ، بدلاً من ذلك ، "أعلن" معالج خطأ ببيان تأجيل:

أعتقد أن هذا سوف يندرج ضمن فئة "التمسك بعبارة if المجربة والصحيحة". آمل أن يتم تحسين الاقتراح لمعالجة هذا أيضًا.

أقترح بشدة أن يعطي فريق Go الأولوية للأدوية ، حيث يسمع Go معظم الانتقادات ، وينتظر معالجة الأخطاء. تقنية اليوم ليست مؤلمة (يجب أن go fmt على سطر واحد).

يحتوي مفهوم try() على جميع مشكلات check من الشيك / المقبض:

1. لا يقرأ مثل Go. يريد الناس بناء جملة الواجب ، بدون اختبار الصفر اللاحق ، حيث يبدو ذلك مثل Go. اقترحت ثلاثة عشر إجابة منفصلة للتحقق / التعامل هذا ؛ انظر _السمات المتكررة_ هنا:
   https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -المواضيع

   f, #      := os.Open(...) // return on error
   f, #panic := os.Open(...) // panic on error
   f, #hname := os.Open(...) // invoke named handler on error
   // # is any available symbol or unambiguous pair
   

2. يؤدي تداخل استدعاءات الوظائف التي ترجع أخطاء إلى حجب ترتيب العمليات ، ويعيق تصحيح الأخطاء. يجب أن تكون الحالة عند حدوث خطأ ، وبالتالي تسلسل الاتصال ، واضحين ، لكن الأمر ليس كذلك:
   try(step4(try(step1()), try(step3(try(step2())))))
   تذكر الآن أن اللغة تمنع:
   f(t ? a : b) و f(a++)

3. سيكون من التافه إرجاع أخطاء بدون سياق. كان الأساس المنطقي الرئيسي للفحص / التعامل هو تشجيع التهيئة للسياق.

4. إنه مرتبط بكتابة error وقيمة الإرجاع الأخيرة. إذا احتجنا إلى فحص قيم / أنواع الإرجاع الأخرى للحالة الاستثنائية ، فنعود إلى: if errno := f(); errno != 0 { ... }

5. لا تقدم مسارات متعددة. الكود الذي يستدعي التخزين أو واجهات برمجة التطبيقات للشبكات يعالج مثل هذه الأخطاء بشكل مختلف عن تلك الناتجة عن الإدخال غير الصحيح أو الحالة الداخلية غير المتوقعة. يقوم الكود الخاص بي بواحد من هذه الأشياء في كثير من الأحيان أكثر من return err :

   • سجل. فادح ()
   • panic () للأخطاء التي لا يجب أن تظهر أبدًا
   • سجل رسالة وأعد المحاولة

gopherbot إضافة Go2، LanguageChange

ماذا عن استخدام ? فقط لإلغاء النتيجة مثل rust

قد يكون سبب تشككنا في استدعاء try () عبارة عن رابطين ضمنيين. لا يمكننا رؤية الارتباط لخطأ القيمة المرجعة والوسيطات الخاصة بـ try (). بالنسبة إلى try () ، يمكننا وضع قاعدة مفادها أننا يجب أن نستخدم try () مع وظيفة الوسيطة التي تحتوي على خطأ في قيم الإرجاع. لكن القيم الملزمة للعودة ليست كذلك. لذلك أعتقد أن المزيد من التعبير مطلوب للمستخدمين لفهم ما تفعله هذه الشفرة.

func doSomething() (int, %error) {
  f := try(foo())
  ...
}

• لا يمكننا استخدام try () إذا لم يكن لدى doSomething %error في قيم الإرجاع.
• لا يمكننا استخدام try () إذا لم يكن لدى foo () خطأ في آخر قيم الإرجاع.

من الصعب إضافة متطلبات / ميزة جديدة إلى البنية الحالية.

لأكون صادقًا ، أعتقد أن foo () يجب أن يحتوي أيضًا على خطأ٪.

أضف قاعدة واحدة أخرى

• يمكن أن يكون الخطأ٪ واحدًا فقط في قائمة القيمة المرجعة للدالة.

في مستند التصميم التفصيلي ، لاحظت أنه في تكرار سابق ، تم اقتراح تمرير معالج الأخطاء إلى وظيفة المحاولة المضمنة. مثله:

handler := func(err error) error {
        return fmt.Errorf("foo failed: %v", err)  // wrap error
}

f := try(os.Open(filename), handler)  

أو أفضل ، مثل هذا:

f := try(os.Open(filename), func(err error) error {
        return fmt.Errorf("foo failed: %v", err)  // wrap error
})  

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

ثانيًا ، لا مانع من أن عنصرًا مضمّنًا يمكن أن يتسبب في عودة الوظيفة ، ولكن ، لركوب الدراجة قليلاً ، فإن الاسم "try" قصير جدًا بحيث لا يشير إلى أنه يمكن أن يتسبب في إرجاع. لذا فإن الاسم الأطول ، مثل attempt يبدو أفضل بالنسبة لي.

تحرير: ثالثًا ، من الناحية المثالية ، يجب أن تكتسب لغة go الأدوية الجنسية أولاً ، حيث ستكون حالة الاستخدام المهمة هي القدرة على تنفيذ وظيفة المحاولة هذه باعتبارها عامة ، بحيث يمكن أن ينتهي التعرق بالدراجات ، ويمكن للجميع الحصول على معالجة الخطأ التي يفضلونها.

تحتوي أخبار القرصنة على بعض النقاط: try لا تتصرف مثل وظيفة عادية (يمكن أن تعود) لذلك ليس من الجيد إعطائها بناء جملة يشبه الوظيفة. سيكون بناء الجملة A return أو defer أكثر ملاءمة:

func CopyFile(src, dst string) (err error) {
        r := try os.Open(src)
        defer r.Close()

        w := try os.Create(dst)
        defer func() {
                w.Close()
                if err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        try io.Copy(w, r)
        try w.Close()
        return nil
}

sheerun الحجة المضادة الشائعة لهذا هو أن panic هو أيضًا وظيفة مضمنة لتغيير التحكم في التدفق. أنا شخصياً لا أتفق معها ، لكنها صحيحة.

1. صدى deanveloper أعلاه ، بالإضافة إلى التعليقات المشابهة للآخرين ، أخشى جدًا أننا نقلل من تكاليف إضافة كلمة رئيسية جديدة ، دقيقة إلى حد ما ، وخاصة عندما تكون مضمنة في استدعاءات وظيفية أخرى - يتم التغاضي عنها بسهولة والتي تدير التحكم في مكدس المكالمات تدفق. panic(...) هو استثناء واضح نسبيًا (التورية ليست مقصودة) لقاعدة أن return هو السبيل الوحيد للخروج من الوظيفة. لا أعتقد أننا يجب أن نستخدم وجودها كمبرر لإضافة ثلث.
2. من شأن هذا الاقتراح أن يجعل إرجاع الخطأ غير المغلف هو السلوك الافتراضي ، ويحيل أخطاء التغليف كشيء يجب عليك الاشتراك فيه ، مع احتفال إضافي. ولكن ، من واقع خبرتي ، فإن ذلك يعود بالضبط إلى الممارسات الجيدة. آمل أن يسهّل الاقتراح في هذا الفضاء ، أو على الأقل ليس أكثر صعوبة ، إضافة معلومات سياقية إلى الأخطاء في موقع الخطأ.

ربما يمكننا إضافة متغير مع وظيفة التعزيز الاختيارية شيء مثل tryf بهذه الدلالات:

func tryf(t1 T1, t1 T2, … tn Tn, te error, fn func(error) error) (T1, T2, … Tn)

يترجم هذا

x1, x2, … xn = tryf(f(), func(err error) { return fmt.Errorf("foobar: %q", err) })

في هذا

t1, … tn, te := f()
if te != nil {
    if fn != nil {
        te = fn(te)
    }
    err = te
    return
}

نظرًا لأن هذا اختيار صريح (بدلاً من استخدام try ) ، يمكننا العثور على إجابات معقولة للأسئلة في الإصدار السابق من هذا التصميم. على سبيل المثال ، إذا كانت وظيفة الزيادة لا شيء ، فلا تفعل أي شيء وقم بإرجاع الخطأ الأصلي فقط.

أشعر بالقلق من أن try سيحل محل معالجة الأخطاء التقليدية ، وأن ذلك سيجعل كتابة مسارات الخطأ أكثر صعوبة نتيجة لذلك.

سيتم اعتبار الكود الذي يعالج الأخطاء عن طريق تسجيل الرسائل وتحديث عدادات القياس عن بُعد معيبًا أو غير لائق من قِبل كل من linters والمطورين الذين يتوقعون try كل شيء.

a, b, err := doWork()
if err != nil {
  updateCounters()
  writeLogs()
  return err
}

Go هي لغة اجتماعية للغاية لها مصطلحات شائعة يتم فرضها بواسطة الأدوات (fmt ، lint ، إلخ). يرجى مراعاة التداعيات الاجتماعية لهذه الفكرة - سيكون هناك ميل لاستخدامها في كل مكان.

politician ، آسف ، لكن الكلمة التي تبحث عنها ليست _ اجتماعية_ بل _مفتوحة_. Go هي لغة برمجة لها رأي. بالنسبة للباقي أتفق في الغالب مع ما تحصل عليه.

تُظهر أدوات مجتمع beoran مثل Godep و linters المختلفة أن Go لها رأي واجتماعي على حد سواء ، والعديد من الأعمال الدرامية مع اللغة تنبع من هذا المزيج. نأمل أن نتفق على أن try لا ينبغي أن يكون الدراما التالية.

olitician شكرًا للتوضيح ، لم أفهم الأمر بهذه الطريقة. يمكنني بالتأكيد أن أتفق على أنه يجب علينا محاولة تجنب الدراما.

أنا في حيرة من أمري حيال ذلك.

من المدونة: الأخطاء هي قيم ، من وجهة نظري ، فهي مصممة بحيث لا يتم تجاهلها.

وأنا أصدق ما قاله روب بايك ، "يمكن برمجة القيم ، وبما أن الأخطاء هي قيم ، يمكن برمجة الأخطاء.".

يجب ألا نعتبر error على أنه exception ، إنه مثل استيراد التعقيد ليس فقط للتفكير ولكن أيضًا للترميز إذا قمنا بذلك.

"استخدم اللغة لتبسيط معالجة الأخطاء." - روب بايك

وأكثر من ذلك ، يمكننا مراجعة هذه الشريحة

من المواقف التي أجد فيها التحقق من الأخطاء عبر if أمرًا محرجًا بشكل خاص عند إغلاق الملفات (على سبيل المثال على NFS). أعتقد ، نحن حاليًا نهدف إلى كتابة ما يلي ، إذا كان الخطأ يعود من .Close() ممكن؟

r, err := os.Open(src)
if err != nil {
    return err
}
defer func() {
    // maybe check whether a previous error occured?
    return r.Close()
}()

هل يمكن أن يكون defer try(r.Close()) طريقة جيدة للحصول على صيغة يمكن إدارتها لطريقة ما للتعامل مع مثل هذه الأخطاء؟ على الأقل ، سيكون من المنطقي تعديل مثال CopyFile() في الاقتراح بطريقة ما ، لعدم تجاهل الأخطاء من r.Close() و w.Close() .

seehuhn لن يتم ترجمة المثال الخاص بك لأن الدالة المؤجلة لا تحتوي على نوع إرجاع.

func doWork() (err error) {
  r, err := os.Open(src)
  if err != nil {
    return err
  }
  defer func() {
    err = r.Close()  // overwrite the return value
  }()
}

سوف تعمل كما تتوقع. المفتاح هو قيمة الإرجاع المسماة.

يعجبني الاقتراح لكني أعتقد أنه يجب إضافة عنوانseehuhn أيضًا:

defer try(w.Close())

سيعيد الخطأ من Close () فقط إذا لم يكن الخطأ قد تم تعيينه بالفعل.
يستخدم هذا النمط في كثير من الأحيان ...

أنا أتفق مع المخاوف المتعلقة بإضافة سياق إلى الأخطاء. أرى أنه أحد أفضل الممارسات التي تجعل رسائل الخطأ ودودة (وواضحة) وتجعل عملية تصحيح الأخطاء أسهل.

أول شيء فكرت فيه هو استبدال fmt.HandleErrorf # $ بوظيفة tryf ، والتي تسبق الخطأ بسياق إضافي.

func tryf(t1 T1, t1 T2, … tn Tn, te error, ts string) (T1, T2, … Tn)

على سبيل المثال (من رمز حقيقي لدي):

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil {
        return nil, errors.WithMessage(err, "load config dir")
    }
    b := bytes.NewBuffer(nil)
    if err = templates.ExecuteTemplate(b, "main", c); err != nil {
        return nil, errors.WithMessage(err, "execute main template")
    }
    buf, err := format.Source(b.Bytes())
    if err != nil {
        return nil, errors.WithMessage(err, "format main template")
    }
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    if err := ioutil.WriteFile(target, buf, 0644); err != nil {
        return nil, errors.WithMessagef(err, "write file %s", target)
    }
    // ...
}

يمكن تغييرها إلى شيء مثل:

func (c *Config) Build() error {
    pkgPath := tryf(c.load(), "load config dir")
    b := bytes.NewBuffer(nil)
    tryf(emplates.ExecuteTemplate(b, "main", c), "execute main template")
    buf := tryf(format.Source(b.Bytes()), "format main template")
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    tryf(ioutil.WriteFile(target, buf, 0644), fmt.Sprintf("write file %s", target))
    // ...
}

أو ، إذا أخذت مثالagnivade :

func (p *pgStore) DoWork() (err error) {
    tx := tryf(p.handle.Begin(), "begin transaction")
        defer func() {
        if err != nil {
            tx.Rollback()
        }
    }()
    var res int64
    tryf(tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res), "insert table")
    _, = tryf(tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res), "insert table2")
    return tryf(tx.Commit(), "commit transaction")
}

ومع ذلك ، أثار josharian نقطة جيدة تجعلني أتردد في هذا الحل:

كما هو مكتوب ، فإنه ينقل تنسيق fmt من حزمة إلى اللغة نفسها ، مما يفتح علبة من الديدان.

أنا موافق تمامًا على هذا الاقتراح ويمكنني رؤية فوائده عبر عدد من الأمثلة.

اهتمامي الوحيد بالاقتراح هو تسمية try ، أشعر أن دلالاته مع اللغات الأخرى ، قد تحرف تصورات deveopers لما هو الغرض منه عندما يأتي من لغات أخرى. تأتي جافا لتجد هنا.

بالنسبة لي ، أفضل أن يُطلق على المضمن اسم pass . أشعر أن هذا يعطي تمثيلًا أفضل لما يحدث. بعد كل شيء ، أنت لا تتعامل مع الخطأ - بدلاً من إعادته ليتم التعامل معه من قبل المتصل. يعطي try الانطباع بأنه تم معالجة الخطأ.

إنها إهانة مني ، ويرجع ذلك أساسًا إلى أن المشكلة التي تهدف إلى معالجتها ("النموذج المعياري إذا كانت العبارات المرتبطة عادةً بمعالجة الأخطاء") ليست مشكلة بالنسبة لي. إذا كانت جميع عمليات التحقق من الأخطاء ببساطة if err != nil { return err } ، فيمكنني أن أرى بعض القيمة في إضافة السكر النحوي لذلك (على الرغم من أن Go هي لغة خالية من السكر نسبيًا من خلال الميل).

في الواقع ، ما أريد القيام به في حالة حدوث خطأ غير معدوم يختلف اختلافًا كبيرًا من حالة إلى أخرى. ربما أريد أن t.Fatal(err) . ربما أريد إضافة رسالة تزيين return fmt.Sprintf("oh no: %v", err) . ربما قمت فقط بتسجيل الخطأ والمتابعة. ربما قمت بتعيين علامة خطأ على كائن SafeWriter الخاص بي والمتابعة ، والتحقق من العلامة في نهاية بعض تسلسل العمليات. ربما أحتاج إلى اتخاذ بعض الإجراءات الأخرى. لا يمكن أتمتة أي من هذه باستخدام try . لذا ، إذا كانت حجة try هي أنها ستزيل كل الكتل if err != nil ، فإن هذه الوسيطة لن تصمد.

هل ستقضي على بعض منها؟ بالتأكيد. هل هذا عرض جذاب بالنسبة لي؟ مه. أنا حقا لست قلقا. بالنسبة لي ، if err != nil هو مجرد جزء من Go ، مثل الأقواس المتعرجة ، أو defer . أتفهم أن الأمر يبدو مطولًا ومتكررًا للأشخاص الجدد على Go ، لكن الأشخاص الجدد في Go ليسوا في أفضل وضع لإجراء تغييرات جذرية على اللغة ، لمجموعة كاملة من الأسباب.

كان شريط التغييرات المهمة على Go تقليديًا هو أن التغيير المقترح يجب أن يحل مشكلة (أ) مهمة ، (ب) تؤثر على الكثير من الناس ، و (ج) تم حلها جيدًا من خلال الاقتراح. لست مقتنعًا بأي من هذه المعايير الثلاثة. أنا سعيد جدًا بمعالجة أخطاء Go كما هي.

لتكرار صدى peterbourgon و deanveloper ، فإن أحد الأشياء المفضلة لدي في Go هو أن تدفق الشفرة واضح ولا يتم التعامل مع الذعر () كآلية قياسية للتحكم في التدفق كما هي في Python.

فيما يتعلق بالنقاش حول الذعر ، فإن الذعر () دائمًا ما يظهر بمفرده على الخط لأنه لا قيمة له. لا يمكنك fmt.Println(panic("oops")) . هذا يزيد من ظهورها بشكل كبير ويجعلها أقل قابلية للمقارنة بـ try() مما يفعله الناس.

إذا كان هناك بنية أخرى للتحكم في التدفق للوظائف ، فسأفضل _far_ أن تكون عبارة مضمونة لتكون العنصر الموجود في أقصى اليسار في السطر.

أحد الأمثلة في الاقتراح يبرز المشكلة بالنسبة لي:

func printSum(a, b string) error {
        fmt.Println(
                "result:",
                try(strconv.Atoi(a)) + try(strconv.Atoi(b)),
        )
        return nil
}

يصبح تدفق التحكم أقل وضوحًا وغموضًا جدًا.

هذا أيضًا ضد النية الأولية لروب بايك بأن جميع الأخطاء تحتاج إلى معالجة صريحة.

في حين أن رد الفعل على هذا يمكن أن يكون "ثم لا تستخدمه" ، فإن المشكلة هي - المكتبات الأخرى سوف تستخدمه ، وتصحيح الأخطاء وقراءتها واستخدامها ، يصبح أكثر إشكالية. سيحفز هذا شركتي على عدم تبني go 2 مطلقًا ، والبدء في استخدام المكتبات فقط التي لا تستخدم try . إذا لم أكن وحدي مع هذا ، فقد يؤدي ذلك إلى تقسيم a-la python 2/3.

أيضًا ، تسمية try ستشير تلقائيًا إلى أن catch سيظهر في النهاية في بناء الجملة ، وسنعود إلى Java.

لذا ، وبسبب كل هذا ، أنا أعارض بشدة هذا الاقتراح.

لا يعجبني اسم try . إنه يعني محاولة _ في القيام بشيء ينطوي على مخاطر عالية للفشل (قد يكون لدي تحيز ثقافي ضد _try_ لأنني لست متحدثًا باللغة الإنجليزية) ، بينما سيتم استخدام try بدلاً من ذلك في حالة توقعنا لإخفاقات نادرة (الدافع وراء الرغبة في تقليل الإسهاب في معالجة الأخطاء) وهم متفائلون. بالإضافة إلى أن try في هذا الاقتراح يؤدي في الواقع _catches_ إلى حدوث خطأ لإعادته مبكرًا. يعجبني اقتراح pass الخاص بـHiImJC.

إلى جانب الاسم ، أجد أنه من المحرج أن يكون عبارة return -like مخفية الآن في منتصف التعبيرات. هذا يكسر نمط التدفق. سيجعل مراجعات الكود أكثر صعوبة.

بشكل عام ، أجد أن هذا الاقتراح لن يفيد إلا المبرمج الكسول الذي لديه الآن سلاح لرمز أقصر وسبب أقل لبذل جهد التفاف الأخطاء. نظرًا لأنه سيجعل المراجعات أكثر صعوبة (العودة في منتصف التعبير) ، أعتقد أن هذا الاقتراح يتعارض مع هدف Go "البرمجة على نطاق واسع".

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

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

ما ينقص هو طريقة مريحة للتفاعل مع اقتراح (مقترحات) فحص الأخطاء على الطاولة. أعتقد أن واجهات برمجة التطبيقات (API) يجب أن تكون متعمدة للغاية فيما يتعلق بأنواع الأخطاء التي تعرضها ، ومن المحتمل أن يكون الخطأ الافتراضي هو "الأخطاء المرتجعة غير القابلة للفحص بأي شكل من الأشكال". يجب أن يكون من السهل بعد ذلك الانتقال إلى حالة يمكن فيها فحص الأخطاء بطريقة دقيقة ، كما هو موثق في توقيع الوظيفة ("يُبلغ عن خطأ من النوع X في الظرف A وخطأ من النوع Y في الظرف B").

لسوء الحظ ، اعتبارًا من الآن ، يجعل هذا الاقتراح الخيار الأكثر راحة هو أكثر الخيارات غير المرغوب فيها (بالنسبة لي) ؛ تمر بشكل أعمى من خلال أنواع الخطأ التعسفي. أعتقد أن هذا غير مرغوب فيه لأنه يشجع على عدم التفكير في أنواع الأخطاء التي ترجعها وكيف سيستهلكها مستخدمو واجهة برمجة التطبيقات الخاصة بك. من المؤكد أن الراحة الإضافية لهذا الاقتراح لطيفة ، لكنني أخشى أنها ستشجع السلوك السيئ لأن الراحة المتصورة ستفوق القيمة المتصورة للتفكير بعناية في معلومات الخطأ التي تقدمها (أو التسريب).

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

قد يكون الحل الآخر هو إعادة توظيف الفكرة (المهملة) الخاصة بالحصول على وسيطة ثانية اختيارية إلى try لتعريف / إدراج نوع (أنواع) الخطأ الذي يمكن إرجاعه من هذا الموقع في القائمة البيضاء. هذا مزعج بعض الشيء لأن لدينا طريقتين مختلفتين لتعريف "نوع الخطأ" ، إما بالقيمة ( io.EOF إلخ) أو حسب النوع ( *os.PathError ، *exec.ExitError ). من السهل تحديد أنواع الأخطاء التي تكون قيمًا كوسيطات لدالة ، ولكن يصعب تحديد الأنواع. لست متأكدًا من كيفية التعامل مع ذلك ، ولكن طرح الفكرة هناك.

يمكن تجنب المشكلة التي أشار إليها josharian عن طريق تأخير تقييم الخطأ:

defer func() { fmt.HandleErrorf(&err, "oops: %v", err) }()

لا يبدو رائعًا ، لكن يجب أن يعمل. لكنني أفضل ما إذا كان من الممكن معالجة ذلك عن طريق إضافة فعل / علامة تنسيق جديدة لمؤشرات الخطأ ، أو ربما للمؤشرات بشكل عام ، والتي تطبع القيمة غير المرجعية كما هو الحال مع %v . لغرض المثال ، دعنا نسميه %*v :

defer fmt.HandleErrorf(&err, "oops: %*v", &err)

بغض النظر عن العقبة ، أعتقد أن هذا الاقتراح يبدو واعدًا ، لكن يبدو أنه من المهم الحفاظ على بيئة العمل لإضافة سياق إلى الأخطاء تحت المراقبة.

يحرر:

هناك طريقة أخرى تتمثل في التفاف مؤشر الخطأ في بنية تنفذ Stringer :

type wraperr struct{ err *error }
func (w wraperr) String() string { return (*w.err).Error() }

...

defer handleErrorf(&err, "oops: %v", wraperr{&err})

زوجان من الأشياء من وجهة نظري. لماذا نحن مهتمون جدًا بحفظ بضعة أسطر من التعليمات البرمجية؟ أنا أعتبر هذا على غرار نفس الدوال الصغيرة التي تعتبر ضارة .

بالإضافة إلى ذلك ، أجد أن مثل هذا الاقتراح من شأنه أن يزيل مسؤولية التعامل مع الخطأ بشكل صحيح إلى بعض "السحر" الذي أخشى أنه سيتم إساءة استخدامه ويشجع الكسل مما يؤدي إلى سوء جودة التعليمات البرمجية والأخطاء.

يحتوي الاقتراح كما هو مذكور أيضًا على عدد من السلوكيات غير الواضحة ، لذا فإن هذا يمثل مشكلة بالفعل من 3 سطور إضافية أكثر وضوحًا.

نستخدم حاليًا نمط التأجيل باعتدال في المنزل. هناك مقال هنا كان له استقبال مختلط بالمثل عندما كتبناه - https://bet365techblog.com/better-error-handling-in-go

ومع ذلك ، كان استخدامنا له توقعًا لتقدم عرض check / handle .

كان الفحص / المقبض نهجًا أكثر شمولاً لجعل معالجة الأخطاء أكثر إيجازًا. احتفظت كتلتها handle بنفس نطاق الوظيفة الذي تم تحديده فيه ، في حين أن أي عبارات defer هي سياقات جديدة مع مبلغ ، مهما كان ، من النفقات العامة. يبدو أن هذا يتماشى أكثر مع مصطلحات go's ، من حيث أنك إذا أردت سلوك "أرجع الخطأ عند حدوثه فقط" يمكنك أن تعلن ذلك صراحةً على أنه handle { return err } .

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

لا يبدو أن try ، في هذه الحالة ، يحل الكثير ، وأنا أشارك الآخرين في الخوف من أنه سيؤدي ببساطة إلى عمليات تنفيذ بطيئة ، أو تلك التي تفرط في استخدام نمط التأجيل.

إذا كانت معالجة الأخطاء القائمة على الإرجاء ستكون شيئًا ، فمن المحتمل أن تتم إضافة شيء كهذا إلى حزمة الأخطاء:

        f := try(os.Create(filename))
        defer errors.Deferred(&err, f.Close)

يعد تجاهل أخطاء بيانات الإغلاق المؤجلة مشكلة شائعة جدًا. يجب أن تكون هناك أداة قياسية للمساعدة في ذلك.

الوظيفة المضمنة التي يتم إرجاعها هي بيع أصعب من الكلمة الرئيسية التي تفعل الشيء نفسه.
أرغب أكثر إذا كانت كلمة رئيسية مثل Zig [1].

1. https://ziglang.org/documentation/master/#try

الوظائف المدمجة ، التي لا يمكن التعبير عن توقيعها النوعي باستخدام نظام نوع اللغة ، والتي يربك سلوكها ماهية الوظيفة بشكل طبيعي ، تبدو وكأنها فتحة هروب يمكن استخدامها بشكل متكرر لتجنب تطور اللغة الفعلي.

لقد اعتدنا على التعرف على عبارات الإرجاع (والذعر) على الفور لأن هذه هي الطريقة التي يتم بها التعبير عن هذا النوع من تدفق التحكم في Go (والعديد من اللغات الأخرى). يبدو أنه ليس بعيد المنال أننا سوف ندرك أيضًا محاولة تغيير تدفق التحكم بعد أن يعتاد البعض عليها ، تمامًا كما نفعل للعودة. ليس لدي شك في أن دعم IDE الجيد سيساعد في هذا أيضًا.

أعتقد أنه بعيد المنال إلى حد ما. في التعليمات البرمجية gofmt'ed ، يتطابق العائد دائمًا مع /^\t*return / - إنه نمط تافه للغاية يمكن ملاحظته بالعين ، دون أي مساعدة. من ناحية أخرى ، يمكن أن يحدث try في أي مكان في الكود ، متداخلاً بشكل تعسفي في عمق استدعاءات الوظائف. لن يجعلنا أي قدر من التدريب قادرين على تحديد كل تدفق التحكم على الفور في وظيفة بدون مساعدة الأداة.

علاوة على ذلك ، فإن الميزة التي تعتمد على "دعم IDE الجيد" ستكون في وضع غير مؤات في جميع البيئات التي لا يوجد فيها دعم جيد لـ IDE. تتبادر إلى الذهن أدوات مراجعة الكود على الفور - هل سيبرز Gerrit كل المحاولات بالنسبة لي؟ ماذا عن الأشخاص الذين يختارون عدم استخدام IDEs ، أو إبراز رمز خيالي ، لأسباب مختلفة؟ هل سيبدأ Acme في تمييز try ؟

يجب أن تكون ميزة اللغة سهلة الفهم من تلقاء نفسها ، لا تعتمد على دعم المحرر.

kungfusheep أحب هذا المقال. يؤدي الاهتمام بالالتفاف في المؤجل وحده بالفعل إلى زيادة إمكانية القراءة قليلاً بدون try .

أنا في المعسكر ولا أشعر أن الأخطاء في Go تمثل مشكلة حقًا. ومع ذلك ، يمكن أن يكون if err != nil { return err } هو التلعثم تمامًا في بعض الوظائف. لقد كتبت وظائف احتاجت إلى التحقق من الأخطاء بعد كل عبارة تقريبًا ولم يكن أي منها بحاجة إلى أي معالجة خاصة بخلاف الالتفاف والإرجاع. في بعض الأحيان ، لا يوجد أي هيكل عازل ذكي سيجعل الأشياء أجمل. في بعض الأحيان تكون مجرد خطوة حاسمة مختلفة تلو الأخرى وتحتاج ببساطة إلى قصر الدائرة إذا حدث خطأ ما.

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

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

هذا يشبه ماكرو بغلاف خاص.

dominikh try يتطابق دائمًا مع /try\(/ لذلك لا أعرف ما هي وجهة نظرك حقًا. إنه قابل للبحث بنفس القدر وكل محرر سمعت عنه لديه ميزة بحث.

qrpnxz أعتقد أن النقطة التي كان يحاول إيضاحها ليست أنه لا يمكنك البحث عنها برمجيًا ، ولكن يصعب البحث عنها بأعينك. كان التعبير العادي مجرد تشبيه ، مع التركيز على /^\t* ، مما يدل على أن جميع المرتجعات تبرز بوضوح من خلال كونها في بداية السطر (تجاهل المسافة البيضاء البادئة).

بالتفكير في الأمر أكثر ، يجب أن يكون هناك وظيفتان مساعدتان مشتركتان. ربما ينبغي أن يكونوا في حزمة تسمى "مؤجلة".

معالجة اقتراح check بالتنسيق لتجنب تسمية المرتجعات ، يمكنك فقط القيام بذلك من خلال وظيفة تتحقق من عدم وجود شيء ، مثل ذلك

func Format(err error, message string, args ...interface{}) error {
    if err == nil {
        return nil
    }
    return fmt.Errorf(...)
}

يمكن استخدام هذا بدون إرجاع مسمى مثل:

func foo(s string) (int, error) {
    n, err := strconv.Atoi(s)
    try(deferred.Format(err, "bad string %q", s))
    return n, nil
}

يمكن وضع fmt.HandleError المقترح في الحزمة المؤجلة بدلاً من ذلك وأخطائي. يمكن تسمية الوظيفة المساعدة المؤجلة deferred.Exec ويمكن أن يكون هناك تنفيذ مشروط للإجراءات ليتم تنفيذها فقط إذا كان الخطأ غير معدوم.

بتجميعها معًا ، تحصل على شيء مثل

func CopyFile(src, dst string) (err error) {
    defer deferred.Annotate(&err, "copy %s %s", src, dst)

    r := try(os.Open(src))
    defer deferred.Exec(&err, r.Close)

    w := try(os.Create(dst))
    defer deferred.Exec(&err, r.Close)

    defer deferred.Cond(&err, func(){ os.Remove(dst) })
    try(io.Copy(w, r))

    return nil
}

مثال آخر:

func (p *pgStore) DoWork() (err error) {
    tx := try(p.handle.Begin())

    defer deferred.Cond(&err, func(){ tx.Rollback() })

    var res int64 
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    try(deferred.Format(err, "insert table")

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    try(deferred.Format(err, "insert table2"))

    return tx.Commit()
}

يأخذنا هذا الاقتراح من وجود if err != nil في كل مكان ، إلى وجود try في كل مكان. إنه يغير المشكلة المقترحة ولا يحلها.

على الرغم من أنني أزعم أن آلية معالجة الأخطاء الحالية ليست مشكلة في البداية. نحتاج فقط إلى تحسين الأدوات والتدقيق حولها.

علاوة على ذلك ، أود أن أزعم أن if err != nil هو في الواقع أكثر قابلية للقراءة من try لأنه لا يفسد سطر لغة منطق الأعمال ، بل يقع أسفلها مباشرة:

file := try(os.OpenFile("thing")) // less readable than, 

file, err := os.OpenFile("thing")
if err != nil {

}

وإذا كان Go سيصبح أكثر سحراً في التعامل مع الأخطاء ، فلماذا لا يمتلكه بالكامل. على سبيل المثال ، يمكن لـ Go استدعاء ضمنيًا try إذا لم يقم المستخدم بتعيين خطأ. علي سبيل المثال:

func getString() (string, error) { ... }

func caller() {
  defer func() {
    if err != nil { ... } // whether `err` must be defined or not is not shown in this example. 
  }

  // would call try internally, because a user is not 
  // assigning an error value. Also, it can add a compile error
  // for "defined and not used err value" if the user does not 
  // handle the error. 
  str := getString()
}

بالنسبة لي ، سيؤدي ذلك في الواقع إلى مشكلة التكرار على حساب السحر وإمكانية القراءة.

لذلك ، أقترح إما أن نحل `` المشكلة '' حقًا كما في المثال أعلاه أو نحافظ على معالجة الخطأ الحالية ولكن بدلاً من تغيير اللغة لحل التكرار والالتفاف ، لا نغير اللغة ولكننا نحسن الأدوات والتدقيق من التعليمات البرمجية لجعل التجربة أفضل.

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

تضمين التغريدة

على الرغم من أنه لن يكون "تغييرًا متواضعًا في المكتبة" ، إلا أنه يمكننا التفكير في قبول خطأ func main () أيضًا.

المشكلة في ذلك هي أنه ليست كل المنصات لديها دلالات واضحة حول ما يعنيه ذلك. تعمل إعادة الكتابة بشكل جيد في برامج Go "التقليدية" التي تعمل على نظام تشغيل كامل - ولكن بمجرد كتابة برنامج ثابت للمتحكم الدقيق أو حتى WebAssembly ، ليس من الواضح تمامًا ما يعنيه os.Exit(1) . حاليًا ، os.Exit عبارة عن مكالمة مكتبة ، لذا فإن تطبيقات Go مجانية فقط لا توفرها. شكل main هو مصدر قلق لغوي بالرغم من ذلك.

سؤال حول العرض ربما يكون أفضل إجابة له هو "لا": كيف يتفاعل try مع المتغيرات؟ إنها الحالة الأولى لدالة متغيرة (ish) لا تحتوي على متغيراتها في الوسيطة الأخيرة. هل هذا مسموح:

var e []error
try(e...)

ترك جانبا لماذا تفعل ذلك من أي وقت مضى. أظن أن الإجابة هي "لا" (وإلا فإن المتابعة هي "ماذا لو كان طول الشريحة الموسعة صفرًا). فقط قم بإحضار ذلك حتى يمكن وضعه في الاعتبار عند صياغة المواصفات في النهاية.

• العديد من أعظم الميزات قيد التنفيذ هي أن العناصر المضمنة الحالية تضمن تدفقًا واضحًا للتحكم ، وأن معالجة الأخطاء واضحة ومُشجعة ، ويتم ثني المطورين بشدة عن كتابة التعليمات البرمجية "السحرية". لا يتوافق عرض try مع هذه المبادئ الأساسية ، حيث سيعزز الاختزال على حساب إمكانية قراءة تدفق التحكم.
• إذا تم اعتماد هذا الاقتراح ، فربما يجب التفكير في إنشاء عبارة مضمنة في try بدلاً من دالة . ثم يكون أكثر اتساقًا مع عبارات التحكم في التدفق الأخرى مثل if . بالإضافة إلى ذلك ، تؤدي إزالة الأقواس المتداخلة إلى تحسين إمكانية القراءة بشكل هامشي.
• مرة أخرى ، إذا تم اعتماد الاقتراح ، فربما يتم تنفيذه دون استخدام defer أو ما شابه. لا يمكن تنفيذه بالفعل في Pure go (كما أشار آخرون) لذلك قد يستخدم أيضًا تنفيذًا أكثر كفاءة تحت الغطاء.

أرى مشكلتين في هذا:

1. يضع الكثير من التعليمات البرمجية المتداخلة داخل الوظائف. هذا يضيف الكثير من العبء المعرفي الإضافي ، في محاولة لتحليل الكود في رأسك.

1. يعطينا الأماكن التي يمكن أن تخرج فيها الشفرة من منتصف العبارة.

رقم 2 أعتقد أنه أسوأ بكثير. جميع الأمثلة هنا عبارة عن مكالمات بسيطة تُرجع خطأً ، ولكن الأهم من ذلك هو هذا:

func doit(abc string) error {
    a := fmt.Sprintf("value of something: %s\n", try(getValue(abc)))
    log.Println(a)
    return nil
}

يمكن الخروج من هذا الرمز في منتصف هذا السباق ، وسيكون من السهل جدًا تفويت هذه الحقيقة.

تصويتي لا. هذا لن يجعل كود go أفضل. لن تجعلها أسهل للقراءة. لن تجعله أكثر قوة.

لقد قلتها من قبل ، وهذا الاقتراح يمثلها - أشعر أن 90٪ من الشكاوى حول Go هي "لا أريد أن أكتب عبارة if أو حلقة". يؤدي هذا إلى إزالة بعض عبارات if البسيطة جدًا ، ولكنه يضيف عبئًا معرفيًا ويجعل من السهل تفويت نقاط الخروج لوظيفة ما.

أريد فقط أن أشير إلى أنه لا يمكنك استخدام هذا بشكل رئيسي وقد يكون مربكًا للمستخدمين الجدد أو عند التدريس. من الواضح أن هذا ينطبق على أي وظيفة لا تُرجع خطأ ولكن أعتقد أن main هي وظيفة خاصة لأنها تظهر في العديد من الأمثلة ..

func main() {
    f := try(os.Open("foo.txt"))
    defer f.Close()
}

لست متأكدًا من قبول تجربة الذعر بشكل رئيسي أيضًا.

بالإضافة إلى ذلك ، لن يكون مفيدًا بشكل خاص في الاختبارات ( func TestFoo(t* testing.T) ) وهو أمر مؤسف :(

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

أفضل شيئًا يشبه المحاولة / الصيد الذي قد يبدو

بافتراض أن foo() معرف كـ

func foo() (int, error) {}

يمكنك بعد ذلك أن تفعل

n := try(foo()) {
    case FirstError:
        // do something based on FirstError
    case OtherError:
        // do something based on OtherError
    default:
        // default behavior for any other error
}

الذي يترجم إلى

n, err := foo()
if errors.Is(err, FirstError) {
    // do something based on FirstError
if errors.Is(err, OtherError) {
    // do something based on OtherError
} else {
    // default behavior for any other error
}

بالنسبة لي ، يعد التعامل مع الأخطاء أحد أهم أجزاء قاعدة التعليمات البرمجية.
بالفعل الكثير من كود go هو if err != nil { return err } ، ويعيد خطأ من أعماق المكدس دون إضافة سياق إضافي ، أو حتى (ربما) أسوأ إضافة سياق عن طريق إخفاء الخطأ الأساسي مع التفاف fmt.Errorf .

يبدو أن توفير كلمة رئيسية جديدة من نوع السحر لا تفعل شيئًا سوى استبدال if err != nil { return err } طريقًا خطيرًا.
الآن سيتم تغليف كل التعليمات البرمجية في مكالمة لتجربتها. هذا جيد إلى حد ما (على الرغم من أن سهولة القراءة) للشفرة التي تتعامل فقط مع أخطاء داخل الحزمة مثل:

func foo() error {
  /// stuff
  try(bar())
  // more stuff
}

لكنني أزعم أن المثال المعطى مروّع نوعًا ما ويترك المتصل يحاول فهم خطأ عميق حقًا في المكدس ، مثل معالجة الاستثناءات إلى حد كبير.
بالطبع ، كل هذا متروك للمطور للقيام بالشيء الصحيح هنا ، لكنه يمنح المطور طريقة رائعة لعدم الاهتمام بأخطائه مع ربما "سنصلح هذا لاحقًا" (ونعلم جميعًا كيف ستسير الأمور ).

أتمنى أن ننظر إلى المشكلة من منظور مختلف عن * "كيف يمكننا تقليل التكرار" والمزيد حول "كيف يمكننا جعل معالجة الأخطاء (المناسبة) أبسط والمطورين أكثر إنتاجية".
يجب أن نفكر في كيفية تأثير ذلك على تشغيل كود الإنتاج.

* ملاحظة: هذا لا يقلل التكرار في الواقع ، فقط يغير ما يتم تكراره ، مع جعل الكود أقل قابلية للقراءة لأن كل شيء مغلف بـ try() .

نقطة أخيرة: قراءة الاقتراح في البداية يبدو لطيفًا ، ثم تبدأ في الدخول في جميع المشاكل (على الأقل تلك المدرجة) وهي مثل "حسنًا ، هذا كثير جدًا".

أدرك أن الكثير من هذا أمر شخصي ، لكنه شيء أهتم به. هذه الدلالات مهمة للغاية.
ما أريد رؤيته هو طريقة لجعل كتابة رمز مستوى الإنتاج والحفاظ عليه أبسط بحيث يمكنك أيضًا ارتكاب أخطاء "صحيحة" حتى بالنسبة لكود مستوى POC / العرض التوضيحي.

نظرًا لأن سياق الخطأ يبدو أنه سمة متكررة ...

الفرضية: تُرجع معظم دالات Go (T, error) مقابل (T1, T2, T3, error)

ماذا لو ، بدلاً من تعريف try على أنه try(T1, T2, T3, error) (T1, T2, T3) قمنا بتعريفه على أنه
try(func (args) (T1, T2, T3, error))(T1, T2, T3) ؟ (هذا تقدير تقريبي)

وهو ما يعني أن البنية النحوية لاستدعاء try هي دائمًا الوسيطة الأولى التي تمثل تعبيرًا يُرجع قيمًا متعددة ، وآخرها خطأ.

بعد ذلك ، مثل make ، يفتح هذا الباب لصيغة مكونة من وسيطتين للمكالمة ، حيث تكون الوسيطة الثانية هي سياق المحاولة (على سبيل المثال ، سلسلة ثابتة ، سلسلة بها %v ، دالة تأخذ وسيطة خطأ وتعيد خطأ آخر وما إلى ذلك.)

لا يزال هذا يسمح بالتسلسل لحالة (T, error) ولكن لم يعد بإمكانك سلسلة عمليات إرجاع متعددة والتي لا تكون IMO مطلوبة عادةً.

@ cpuguy83 إذا قرأت الاقتراح فسترى أنه لا يوجد شيء يمنعك من تغليف الخطأ. في الواقع ، هناك طرق متعددة للقيام بذلك مع الاستمرار في استخدام try . يبدو أن الكثير من الناس يفترضون ذلك لسبب ما.

if err != nil { return err } متساوي مع عبارة "سنصلح هذا لاحقًا" مثل try باستثناء المزيد من الإزعاج عند إنشاء النماذج الأولية.

لا أعرف كيف أن وجود الأشياء داخل زوج من الأقواس يكون أقل قابلية للقراءة من خطوات الوظيفة التي تكون كل أربعة أسطر من النموذج المعياري أيضًا.

سيكون من الجيد أن أشرت إلى بعض "المشاكل" المعينة التي أزعجتك لأن هذا هو الموضوع.

يبدو أن قابلية القراءة تمثل مشكلة ولكن ماذا عن تقديم try () بحيث تبرز ، شيء مثل:

f := try(
    os.Open("file.txt")
)

تضمين التغريدة

المشكلة التي أواجهها هي أنها تفترض أنك تريد دائمًا إرجاع الخطأ عند حدوثه.

أنا أعترض. يفترض أنك تريد أن تفعل ذلك في كثير من الأحيان بما يكفي لتبرير اختصار لذلك. إذا لم تقم بذلك ، فلن يعيقك التعامل مع الأخطاء بشكل واضح.

عندما ترغب في إضافة سياق إلى الخطأ وإعادته أو ربما تريد فقط التصرف بشكل مختلف عند حدوث خطأ.

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

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

boomlinde بالضبط وجهة نظري. يحاول هذا الاقتراح حل حالة استخدام فردية بدلاً من توفير أداة لحل المشكلة الأكبر المتعلقة بمعالجة الأخطاء. أعتقد أن السؤال الأساسي هو بالضبط ما أشرت إليه.

يفترض أنك تريد أن تفعل ذلك في كثير من الأحيان بما يكفي لتبرير اختصار لذلك.

في رأيي وخبرتي ، حالة الاستخدام هذه هي أقلية صغيرة ولا تستدعي صياغة مختصرة.

كما أن أسلوب استخدام defer للتعامل مع الأخطاء به مشكلات من حيث أنه يفترض أنك تريد التعامل مع جميع الأخطاء المحتملة بنفس الطريقة. لا يمكن إلغاء كشف defer .

defer fmt.HandleErrorf(&err, “foobar”)

n := try(foo())

x : try(foo2())

ماذا لو أردت معالجة أخطاء مختلفة للأخطاء التي قد يتم إرجاعها من foo() مقابل foo2() ؟

تضمين التغريدة

ماذا لو أردت معالجة أخطاء مختلفة للأخطاء التي قد يتم إرجاعها من foo () مقابل foo2 ()؟

ثم تستخدم شيئًا آخر. هذه هي النقطة التي أثارهاboomlinde .

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

تضمين التغريدة

f := try(os.Open("/foo"))
data := try(ioutil.ReadAll(f))
try(send(data))

(نعم أفهم أن هناك ReadFile وأن هذا المثال بالذات ليس أفضل طريقة لنسخ البيانات في مكان ما ، وليس النقطة)

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

في حالة الصدأ ، يكون العامل على الأقل هو postfix (تمت إضافة ? إلى نهاية المكالمة) والذي لا يضع عبئًا إضافيًا لاستكشاف المنطق الفعلي.

التحكم في التدفق القائم على التعبير

قد تكون panic وظيفة أخرى للتحكم في التدفق ، لكنها لا تُرجع قيمة ، مما يجعلها بيانًا فعالاً. قارن هذا بـ try ، وهو تعبير يمكن أن يحدث في أي مكان.

recover له قيمة ويؤثر على التحكم في التدفق ، ولكن يجب أن يحدث في بيان defer . هذه defer s عادةً ما تكون حرفية وظيفية ، recover يُطلق عليها مرة واحدة فقط ، وبالتالي فإن recover يحدث أيضًا بشكل فعال كإفادة. مرة أخرى ، قارن هذا بـ try والذي يمكن أن يحدث في أي مكان.

أعتقد أن هذه النقاط تعني أن try يجعل من الصعب بشكل كبير متابعة تدفق التحكم بطريقة لم نقم بها من قبل ، كما أشرنا من قبل ، لكنني لم أر الفرق بين العبارات والتعبيرات أشار.

اقتراح آخر

السماح بعبارات مثل

if err != nil {
    return nil, 0, err
}

ليتم تنسيقها على سطر واحد بواسطة gofmt عندما تحتوي الكتلة فقط على عبارة return ولا تحتوي هذه العبارة على أسطر جديدة. علي سبيل المثال:

if err != nil { return nil, 0, err }

المنطق

• لا يتطلب أي تغييرات لغوية
• قاعدة التنسيق بسيطة وواضحة
• يمكن تصميم القاعدة للاشتراك حيث يحتفظ gofmt بأسطر جديدة إذا كانت موجودة بالفعل (مثل البنية الحرفية). يسمح الاشتراك أيضًا للكاتب بالتركيز على بعض معالجة الأخطاء
• إذا لم يتم الاشتراك ، فيمكن نقل الكود تلقائيًا إلى النمط الجديد باستدعاء gofmt
• إنها فقط لكشوفات الحساب return ، لذلك لن يتم إساءة استخدامها في رمز الجولف دون داع
• يتفاعل جيدًا مع التعليقات التي تصف سبب حدوث بعض الأخطاء وسبب إعادتها. يؤدي استخدام العديد من التعبيرات المتداخلة try معالجة هذا الأمر بشكل سيء
• يقلل المساحة الرأسية لمعالجة الأخطاء بنسبة 66٪
• لا يوجد تدفق تحكم قائم على التعبير
• تتم قراءة الكود أكثر بكثير مما هو مكتوب ، لذلك يجب تحسينه للقارئ. الكود المتكرر الذي يشغل مساحة أقل مفيد للقارئ ، حيث يميل try أكثر نحو الكاتب
• لقد اقترح الأشخاص بالفعل try الموجود في أسطر متعددة. على سبيل المثال هذا التعليق أو هذا التعليق الذي يقدم أسلوبًا مثل

f, err := os.Open(file)
try(maybeWrap(err))

• يزيل نمط "try on its own line" أي غموض حول القيمة التي يتم إرجاعها err . لذلك ، أظن أن هذا النموذج سيستخدم بشكل شائع. السماح بمحاذاة واحدة إذا كانت الكتل هي نفس الشيء تقريبًا ، باستثناء أنها أيضًا واضحة حول ماهية القيم المرتجعة
• لا يروج لاستخدام المرتجعات المسماة أو التغليف غير الواضح المستند إلى defer . كلاهما يرفع حاجز التفاف الأخطاء ، وقد يتطلب الأول تغيير godoc
• لا داعي لإجراء مناقشة حول وقت استخدام try مقابل استخدام معالجة الأخطاء التقليدية
• لا يمنع عمل try أو أي شيء آخر في المستقبل. قد يكون التغيير إيجابيًا حتى إذا تم قبول try
• لا يوجد تفاعل سلبي مع مكتبة testing أو وظائف main . في الواقع ، إذا كان الاقتراح يسمح بأي جملة مفردة مسطرة بدلاً من مجرد إرجاع ، فقد يقلل من استخدام المكتبات القائمة على التأكيد. انصح

value, err := something()
if err != nil { t.Fatal(err) }

• لا يوجد تفاعل سلبي مع التحقق من أخطاء معينة. انصح

n, err := src.Read(buf)
if err == io.EOF { return nil }
else if err != nil { return err }

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

من https://github.com/golang/go/issues/32437#issuecomment -498941435

مع المحاولة

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        try(dbfile.RunMigrations(db, dbMigrations))
        t := &Thing{
                thingy:  thingy,
                scanner: try(newScanner(thingy, db, client)),
        }
        t.initOtherThing()
        return t, nil
}

مع هذا

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        err := dbfile.RunMigrations(db, dbMigrations))
        if err != nil { return nil, fmt.Errorf("running migrations: %v", err) }

        t := &Thing{thingy: thingy}
        t.scanner, err = newScanner(thingy, db, client)
        if err != nil { return nil, fmt.Errorf("creating scanner: %v", err) }

        t.initOtherThing()
        return t, nil
}

إنها منافسة في استخدام المساحة بينما لا تزال تسمح بإضافة سياق إلى الأخطاء.

من https://github.com/golang/go/issues/32437#issuecomment -499007288

مع المحاولة

func (c *Config) Build() error {
    pkgPath := try(c.load())
    b := bytes.NewBuffer(nil)
    try(emplates.ExecuteTemplate(b, "main", c))
    buf := try(format.Source(b.Bytes()))
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    try(ioutil.WriteFile(target, buf, 0644))
    // ...
}

مع هذا

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil { return nil, errors.WithMessage(err, "load config dir") }

    b := bytes.NewBuffer(nil)
    err = templates.ExecuteTemplate(b, "main", c)
    if err != nil { return nil, errors.WithMessage(err, "execute main template") }

    buf, err := format.Source(b.Bytes())
    if err != nil { return nil, errors.WithMessage(err, "format main template") }

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    err = ioutil.WriteFile(target, buf, 0644)
    if err != nil { return nil, errors.WithMessagef(err, "write file %s", target) }
    // ...
}

استخدم التعليق الأصلي tryf افتراضيًا لإرفاق التنسيق الذي تمت إزالته. ليس من الواضح أفضل طريقة لإضافة جميع السياقات المميزة ، وربما لا يمكن تطبيق try حتى.

يارب احفظها
بالنسبة لي هو أكثر قابلية للقراءة مع try . في هذا المثال قرأت "افتح ملفًا ، واقرأ كل البايت ، وأرسل البيانات". من خلال معالجة الأخطاء المعتادة ، سأقرأ "افتح ملفًا ، وتحقق مما إذا كان هناك خطأ ، ومعالجة الخطأ تفعل ذلك ، ثم اقرأ جميع وحدات البايت ، وتحقق الآن مما إذا كانت هناك أشياء قد حدثت ..." أعلم أنه يمكنك إجراء مسح ضوئي من خلال err != nil s ، ولكن بالنسبة لي ، فإن try أسهل فقط لأنني عندما أراه أعرف السلوك على الفور: إرجاع إذا أخطأ! = لا شيء. إذا كان لديك فرع يجب أن أرى ما يفعله. يمكن أن تفعل أي شيء.

أود أن أزعم أيضًا أن معالج تأجيل الخطأ هنا لن يكون جيدًا باستثناء مجرد التفاف الخطأ برسالة جديدة

أنا متأكد من أن هناك أشياء أخرى يمكنك القيام بها في المؤجل ، ولكن بغض النظر ، فإن try مخصص للحالة العامة البسيطة على أي حال. في أي وقت تريد أن تفعل شيئًا أكثر ، هناك دائمًا معالجة جيدة لأخطاء ol 'Go. هذا لن ينتهي.

zeebo Yep ، أنا مع ذلك.
استخدمت مقالة kungfusheep التحقق من الخطأ في سطر واحد مثل هذا وخرجت من تجربته. ثم بمجرد أن أنقذ ، وسعته الحكومة إلى ثلاثة أسطر وهو أمر محزن. يتم تعريف العديد من الوظائف في stdlib في سطر واحد مثل هذا ، لذلك فاجأني أن gofmt ستوسع ذلك.

تضمين التغريدة

لقد قرأت الكثير من كود go. أحد أفضل الأشياء المتعلقة باللغة هي السهولة التي تأتي من معظم التعليمات البرمجية التي تتبع أسلوبًا معينًا (شكرًا gofmt).
لا أريد قراءة مجموعة من الأكواد ملفوفة بـ try(f()) .
هذا يعني أنه سيكون هناك تباعد في أسلوب / ممارسة الكود ، أو نصوص مثل "أوه كان يجب أن تستخدم try() هنا" (وهو الأمر الذي لا أحبه مرة أخرى ، وهذا هو الهدف مني والآخرين الذين علقوا على هذا الاقتراح).

إنه ليس أفضل من الناحية الموضوعية من if err != nil { return err } ، فقط أقل للكتابة.

شيء أخير:

إذا قرأت الاقتراح ، فسترى أنه لا يوجد ما يمنعك من ذلك

هل يمكننا الامتناع عن مثل هذه اللغة من فضلك؟ بالطبع قرأت الاقتراح. لقد صادف أنني قرأته الليلة الماضية ثم علقت هذا الصباح بعد التفكير فيه ولم أشرح التفاصيل الدقيقة لما قصدته.
هذه نبرة عدائية بشكل لا يصدق.

يارب احفظها
رجل وحدة المعالجة المركزية السيئ الخاص بي. لم أقصد ذلك بهذه الطريقة.

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

تأكد من أنها ليست أفضل من الناحية الموضوعية. كنت أعبر عن أنه كان أكثر قابلية للقراءة بالنسبة لي . لقد قمت بصياغة ذلك بعناية.

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

https://github.com/golang/go/issues/32437#issuecomment -498908380

لا أحد سوف يجعلك تستخدم المحاولة.

بتجاهل البراعة ، أعتقد أن هذه طريقة مموجة يدويًا لرفض انتقادات التصميم.

بالتأكيد ، لست مضطرًا لاستخدامه. لكن أي شخص أكتب معه رمز يمكنه استخدامه ويجبرني على محاولة فك تشفير try(try(try(to()).parse().this)).easily()) . إنه مثل القول

لن يجعلك أحد تستخدم الواجهة الفارغة {}.

على أي حال ، Go صارم للغاية بشأن البساطة: gofmt يجعل كل الكود يبدو بنفس الطريقة. يبقى المسار السعيد يسارًا وأي شيء قد يكون مكلفًا أو مفاجئًا يكون واضحًا . try كما هو مقترح هو تحول 180 درجة من هذا. البساطة! = موجزة.

على الأقل ، يجب أن تكون try كلمة رئيسية ذات قيم.

ليس من المفترض أن يكون أفضل من if err != nil { return err } ، فقط أقل للكتابة.

هناك اختلاف موضوعي واحد بين الاثنين: try(Foo()) تعبير. بالنسبة للبعض ، يعتبر هذا الاختلاف جانبًا سلبيًا (النقد try(strconv.Atoi(x))+try(strconv.Atoi(y)) ). بالنسبة للآخرين ، يعتبر هذا الاختلاف اتجاهًا إيجابيًا لنفس السبب. ما زلت ليس أفضل أو أسوأ من الناحية الموضوعية - لكنني أيضًا لا أعتقد أنه يجب إزالة الاختلاف تحت السجادة والادعاء بأنه "أقل من الكتابة" لا ينصف الاقتراح.

@ elagergren-spideroak يصعب القول إن try مزعج لرؤية نفس واحد ثم القول إنه ليس صريحًا في اليوم التالي. يجب عليك اختيار واحد.

من الشائع رؤية وسيطات الوظيفة يتم وضعها في المتغيرات المؤقتة أولاً. أنا متأكد من أنه سيكون أكثر شيوعًا أن نرى

this := try(to()).parse().this
that := try(this.easily())

من مثالك.

try عدم القيام بأي شيء هو الطريق السعيد ، لذلك يبدو كما هو متوقع. في الطريق التعيس كل ما يفعله هو العودة. رؤية أن هناك try يكفي لجمع تلك المعلومات. ليس هناك أي شيء مكلف للرجوع من وظيفة أيضًا ، لذلك من هذا الوصف لا أعتقد أن try يقوم بـ 180

josharian فيما يتعلق بتعليقك في https://github.com/golang/go/issues/32437#issuecomment -498941854 ، لا أعتقد أن هناك خطأ تقييم مبكر هنا.

تأجيل fmt.HandleErrorf (& err، “foobar:٪ v”، err)

تم تمرير القيمة غير المعدلة البالغة err إلى HandleErrorf ، وتم تمرير مؤشر إلى err . نتحقق مما إذا كان err هو nil (باستخدام المؤشر). إذا لم يكن الأمر كذلك ، نقوم بتنسيق السلسلة باستخدام القيمة غير المعدلة وهي err . ثم قمنا بتعيين err على قيمة الخطأ المنسق باستخدام المؤشر.

Merovius الاقتراح هو في الحقيقة مجرد بناء جملة ماكرو السكر ، لذلك سينتهي به الأمر حول ما يعتقده الناس أنه يبدو أجمل أو أنه سيسبب أقل مشكلة. إذا كنت تعتقد لا ، من فضلك اشرح لي. لهذا السبب أنا شخصيا. إنها إضافة رائعة دون إضافة أي كلمات رئيسية من وجهة نظري.

ianlancetaylor ، أعتقد أن josharian صحيح: القيمة "غير المعدلة" لـ err هي القيمة في الوقت الذي يتم فيه دفع defer إلى المكدس ، وليست القيمة (المقصودة على الأرجح) err تم تعيينها بواسطة try قبل العودة.

المشكلة الأخرى التي أواجهها مع try هي أنها تجعل الأمر أسهل بكثير على الناس لإلقاء المزيد من المنطق في سطر واحد. هذه هي مشكلتي الرئيسية مع معظم اللغات الأخرى ، هي أنها تجعل من السهل حقًا وضع مثل 5 تعبيرات في سطر واحد ، ولا أريد ذلك.

this := try(to()).parse().this
that := try(this.easily())

^ ^ حتى هذا فظيع تمامًا. السطر الأول ، يجب أن أقفز ذهابًا وإيابًا لأقوم بمطابقة أقواس في رأسي. حتى السطر الثاني الذي هو في الواقع بسيط للغاية ... من الصعب حقًا قراءته.
يصعب قراءة الوظائف المتداخلة.

parser, err := to()
if err != nil {
    return err
}
this := parser.parse().this
that, err := this.easily()
if err != nil {
    return err
}

^ ^ هذا هو IMO أسهل بكثير وأفضل. إنه بسيط للغاية وواضح. نعم ، إنها سطور أكثر بكثير من التعليمات البرمجية ، لا يهمني. من الواضح جدا.

bcmillsjosharian آه ، بالطبع ، شكرا. لذلك يجب أن يكون

defer func() { fmt.HandleErrorf(&err, “foobar: %v”, err) }()

ليس لطيفا. ربما يجب أن يمرر fmt.HandleErrorf قيمة الخطأ ضمنيًا باعتبارها الوسيطة الأخيرة بعد كل شيء.

لقد حصلت هذه القضية على الكثير من التعليقات بسرعة كبيرة ، ويبدو لي أن العديد منها يكرر التعليقات التي تم الإدلاء بها بالفعل. بالطبع لا تتردد في التعليق ، لكني أود أن أقترح برفق أنه إذا كنت تريد إعادة ذكر نقطة تم توضيحها بالفعل ، فعليك القيام بذلك باستخدام الرموز التعبيرية لـ GitHub ، بدلاً من تكرار النقطة. شكرا.

ianlancetaylor إذا أرسل fmt.HandleErrorf خطأ كأول وسيطة بعد التنسيق ، فسيكون التنفيذ أفضل وسيكون المستخدم قادرًا على الرجوع إليه بواسطة %[1]v دائمًا.

natefinch أتفق تماما.

أتساءل عما إذا كان نهج أسلوب الصدأ سيكون أكثر قبولا؟
لاحظ أن هذا ليس اقتراحًا فقط أفكر فيه ...

this := to()?.parse().this
that := this.easily()?

في النهاية ، أعتقد أن هذا أجمل ، ولكن (يمكن استخدام ! أو أي شيء آخر أيضًا ...) ، ولكن لا يزال لا يصلح مشكلة التعامل مع الأخطاء بشكل جيد.

بالطبع يحتوي الصدأ أيضًا على try() تمامًا مثل هذا ، ولكن ... نمط الصدأ الآخر.

ليس من المفترض أن يكون أفضل من if err != nil { return err } ، فقط أقل للكتابة.

هناك اختلاف موضوعي واحد بين الاثنين: try(Foo()) تعبير. بالنسبة للبعض ، يعتبر هذا الاختلاف جانبًا سلبيًا (النقد try(strconv.Atoi(x))+try(strconv.Atoi(y)) ). بالنسبة للآخرين ، يعتبر هذا الاختلاف اتجاهًا إيجابيًا لنفس السبب. ما زلت ليس أفضل أو أسوأ من الناحية الموضوعية - لكنني أيضًا لا أعتقد أنه يجب إزالة الاختلاف تحت السجادة والادعاء بأنه "أقل من الكتابة" لا ينصف الاقتراح.

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

تضمين التغريدة

بالضبط وجهة نظري. يحاول هذا الاقتراح حل حالة استخدام فردية بدلاً من توفير أداة لحل المشكلة الأكبر المتعلقة بمعالجة الأخطاء. أعتقد أن السؤال الأساسي هو بالضبط ما أشرت إليه.

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

في رأيي وخبرتي ، حالة الاستخدام هذه هي أقلية صغيرة ولا تستدعي صياغة مختصرة.

في مصدر Go ، هناك آلاف الحالات التي يمكن معالجتها بواسطة try خارج الصندوق حتى لو لم تكن هناك طريقة لإضافة سياق إلى الأخطاء. إذا كان قاصرًا ، فلا يزال سببًا شائعًا للشكوى.

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

وبالمثل ، فإن طريقة استخدام + للتعامل مع الحساب تفترض أنك لا تريد الطرح ، لذا فأنت لا تريد ذلك إذا لم ترغب في ذلك. السؤال المثير للاهتمام هو ما إذا كان سياق الخطأ على مستوى الكتلة يمثل على الأقل نمطًا شائعًا.

ماذا لو أردت معالجة أخطاء مختلفة للأخطاء التي قد يتم إرجاعها من foo () مقابل foo2 ()

مرة أخرى ، فأنت لا تستخدم try . ثم لا تكسب شيئًا من try ، لكنك أيضًا لا تخسر شيئًا.

يارب احفظها

أتساءل عما إذا كان نهج أسلوب الصدأ سيكون أكثر قبولا؟

يقدم الاقتراح حجة ضد هذا.

في هذه المرحلة ، أعتقد أن وجود try{}catch{} أكثر قابلية للقراءة: upside_down_face:

1. إن استخدام الواردات المسماة للتغلب على حالات الزاوية defer ليس فقط مروعًا لأشياء مثل godoc ، ولكن الأهم من ذلك أنه عرضة للخطأ. لا يهمني أنه يمكنني إنهاء الأمر برمته بدولار func() آخر للتغلب على المشكلة ، إنها مجرد أشياء أخرى أحتاج إلى وضعها في الاعتبار ، وأعتقد أنها تشجع على "ممارسة سيئة".

2. لا أحد سوف يجعلك تستخدم المحاولة.

   هذا لا يعني أنه حل جيد ، فأنا أوضح نقطة أن الفكرة الحالية بها عيب في التصميم وأطلب معالجتها بطريقة أقل عرضة للخطأ.

3. أعتقد أن أمثلة مثل try(try(try(to()).parse().this)).easily()) غير واقعية ، ويمكن فعل ذلك بالفعل مع وظائف أخرى وأعتقد أنه سيكون من العدل لأولئك الذين يراجعون الكود أن يطلبوا تقسيمها.

4. ماذا لو كان لدي 3 أماكن يمكن أن أخطئ فيها وأريد أن أغلق كل مكان على حدة؟ try() يجعل هذا الأمر صعبًا للغاية ، في الواقع try() يثبط بالفعل أخطاء التغليف نظرًا لصعوبة ذلك ، ولكن إليك مثال على ما أعنيه:

   func before() error {
     x, err := foo()
     if err != nil {
       wrap(err, "error on foo")
     }
     y, err := bar(x)
     if err != nil {
       wrapf(err, "error on bar with x=%v", x)
     }
     fmt.Println(y)
     return nil
   }
   
   func after() (err error) {
     defer fmt.HandleErrorf(&err, "something failed but I don't know where: %v", err)
     x := try(foo())
     y := try(bar(x))
     fmt.Println(y)
     return nil
   }
   

5. مرة أخرى ، فأنت لا تستخدم try . ثم لا تكسب شيئًا من try ، لكنك أيضًا لا تخسر شيئًا.

   لنفترض أن التفاف الأخطاء بسياق مفيد يعد ممارسة جيدة ، فسيتم اعتبار try() ممارسة سيئة لأنه لا يضيف أي سياق. هذا يعني أن try() هي ميزة لا يرغب أحد في استخدامها وتصبح ميزة يتم استخدامها نادرًا جدًا لدرجة أنها قد لا تكون موجودة.

   بدلاً من مجرد قول "حسنًا ، إذا لم تعجبك ، فلا تستخدمه وتصمت" (هذه هي الطريقة التي تقرأ بها) ، أعتقد أنه سيكون من الأفضل محاولة معالجة ما يفكر فيه كثير من الاستخدامات في وجود خطأ في التصميم. هل يمكننا بدلاً من ذلك مناقشة ما يمكن تعديله من التصميم المقترح بحيث يتم التعامل مع مخاوفنا بطريقة أفضل؟

boomlinde النقطة التي نتفق عليها هي أن هذا الاقتراح يحاول حل حالة استخدام ثانوية وحقيقة أنه "إذا لم تكن بحاجة إليه ، فلا تستخدمه" هي الحجة الأساسية التي تدعم هذه النقطة. كما ذكر @ elagergren-spideroak ، فإن هذه الحجة لا تعمل لأنه حتى لو لم أرغب في استخدامها ، فإن الآخرين سيفعلون ذلك مما يجبرني على استخدامها. وفقًا لمنطق حجتك ، يجب أن يكون لـ Go أيضًا بيان ثلاثي. وإذا كنت لا تحب العبارات الثلاثية ، فلا تستخدمها.

إخلاء المسؤولية - أعتقد أن Go يجب أن يكون لديه بيان ثلاثي ، لكن بالنظر إلى أن نهج Go لميزات اللغة هو عدم تقديم ميزات يمكن أن تجعل قراءة الكود أكثر صعوبة ، فلا ينبغي.

شيء آخر يحدث لي: أرى الكثير من الانتقادات على أساس فكرة أن وجود try قد يشجع المطورين على التعامل مع الأخطاء بلا مبالاة. لكن في رأيي هذا صحيح أكثر بالنسبة للغة الحالية ؛ إن النموذج المعياري لمعالجة الأخطاء مزعج بدرجة كافية لدرجة أنه يشجع المرء على ابتلاع أو تجاهل بعض الأخطاء لتجنبها. على سبيل المثال ، لقد كتبت أشياء مثل هذه عدة مرات:

func exists(filename string) bool {
  _, err := os.Stat(filename)
  return err == nil
}

لكي تتمكن من كتابة if exists(...) { ... } ، على الرغم من أن هذا الرمز يتجاهل بصمت بعض الأخطاء المحتملة. إذا كان لديّ try ، فربما لن أزعج نفسي للقيام بذلك وأعيد (bool, error) .

كونك فوضوياً هنا ، سأطرح فكرة إضافة دالة مضمنة ثانية تسمى catch والتي ستتلقى وظيفة تأخذ خطأ وتعيد خطأ مكتوبًا ، ثم إذا كان catch لاحق يطلق عليه من شأنه الكتابة فوق المعالج. علي سبيل المثال:

func catch(handler func(err error) error) {
  // .. impl ..
}

الآن ، ستكون هذه الوظيفة المضمنة أيضًا دالة تشبه الماكرو والتي من شأنها معالجة الخطأ التالي الذي سيتم إرجاعه بواسطة try مثل هذا:

func wrapf(format string, ...values interface{}) func(err error) error {
  // user defined
  return func(err error) error {
    return fmt.Errorf(format + ": %v", ...append(values, err))
  }
}
func sample() {
  catch(wrapf("something failed in foo"))
  try(foo()) // "something failed in foo: <error>"
  x := try(foo2()) // "something failed in foo: <error>"
  // Subsequent calls for catch overwrite the handler
  catch(wrapf("something failed in bar with x=%v", x))
  try(bar(x)) // "something failed in bar with x=-1: <error>"
}

هذا أمر رائع لأنني أستطيع التفاف الأخطاء بدون defer والذي يمكن أن يكون عرضة للخطأ ما لم نستخدم قيم إرجاع مسماة أو التفاف مع func آخر ، فهو أيضًا لطيف لأن defer سيضيف نفس معالج الأخطاء لـ جميع الأخطاء حتى لو كنت أرغب في التعامل مع اثنين منهم بشكل مختلف. يمكنك أيضًا استخدامه كما تراه مناسبًا ، على سبيل المثال:

func foo(a, b string) (int64, error) {
  return try(strconv.Atoi(a)) + try(strconv.Atoi(b))
}
func withContext(a, b string) (int64, error) {
  catch(func (err error) error {
    return fmt.Errorf("can't parse a: %s, b: %s, err: %v", a, b, err)
  })
  return try(strconv.Atoi(a)) + try(strconv.Atoi(b))
}
func moreExplicitContext(a, b string) (int64, error) {
  catch(func (err error) error {
    return fmt.Errorf("can't parse a: %s, err: %v", a, err)
  })
  x := try(strconv.Atoi(a))
  catch(func (err error) error {
    return fmt.Errorf("can't parse b: %s, err: %v", b, err)
  })
  y := try(strconv.Atoi(b))
  return x + y
}
func withHelperWrapf(a, b string) (int64, error) {
  catch(wrapf("can't parse a: %s", a))
  x := try(strconv.Atoi(a))
  catch(wrapf("can't parse b: %s", b))
  y := try(strconv.Atoi(b))
  return x + y
}
func before(a, b string) (int64, error) {
  x, err := strconv.Atoi(a)
  if err != nil {
    return 0,  fmt.Errorf("can't parse a: %s, err: %v", a, err)
  }
  y, err := strconv.Atoi(b)
  if err != nil {
    return 0,  fmt.Errorf("can't parse b: %s, err: %v", b, err)
  }
  return x + y
}

وما زلت في حالة مزاجية فوضوية (لمساعدتك على التعاطف) إذا كنت لا تحب catch ، فلن تضطر إلى استخدامه.

الآن ... أنا لا أعني أنها الجملة الأخيرة ، لكن يبدو أنها ليست مفيدة للمناقشة ، IMO شديدة العدوانية.
ومع ذلك ، إذا سلكنا هذا الطريق ، أعتقد أنه قد يكون لدينا أيضًا try{}catch(error err){} بدلاً من ذلك: stuck_out_tongue:

راجع أيضًا # 27519 - نموذج الخطأ # id / catch

لا أحد سوف يجعلك تستخدم المحاولة.

بتجاهل البراعة ، أعتقد أن هذه طريقة مموجة يدويًا لرفض انتقادات التصميم.

آسف ، لم يكن glib هو نيتي.

ما أحاول قوله هو أن try لا يُقصد به أن يكون حلاً بنسبة 100٪. هناك العديد من نماذج معالجة الأخطاء التي لا يتم التعامل معها بشكل جيد بواسطة try . على سبيل المثال ، إذا كنت بحاجة إلى إضافة سياق يعتمد على موقع الاتصال إلى الخطأ. يمكنك دائمًا الرجوع إلى استخدام if err != nil { للتعامل مع تلك الحالات الأكثر تعقيدًا.

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

لذا من خلال "لن يجعلك أحد تستخدم المحاولة" ، أعني أنني أعتقد أن المثال المعني هو 10٪ ، وليس 90٪. هذا التأكيد مطروح بالتأكيد للنقاش ، ويسعدني سماع الحجج المضادة. ولكن في النهاية سيتعين علينا رسم الخط في مكان ما ونقول "نعم ، try لن يتعامل مع هذه الحالة. سيتعين عليك استخدام أسلوب معالجة الأخطاء القديم. معذرة."

ليس الأمر أن "المحاولة لا تستطيع التعامل مع هذه الحالة المحددة لمعالجة الأخطاء" هي المشكلة ، إنها "المحاولة تشجعك على عدم تغليف أخطائك". أجبرتك فكرة check-handle على كتابة بيان إرجاع ، لذا فإن كتابة التفاف للخطأ كان تافهًا للغاية.

بموجب هذا الاقتراح ، تحتاج إلى استخدام عائد مسمى defer ، وهو ليس بديهيًا ويبدو مبتذلًا للغاية.

أجبرتك فكرة check-handle على كتابة بيان إرجاع ، لذا فإن كتابة التفاف للخطأ كان تافهًا للغاية.

هذا ليس صحيحًا - في مسودة التصميم ، كل دالة تقوم بإرجاع خطأ لها معالج افتراضي يقوم بإرجاع الخطأ فقط.

بناءً على النقطة الوقحة في Goodwine ، لا تحتاج حقًا إلى وظائف منفصلة مثل HandleErrorf إذا كان لديك وظيفة جسر واحد مثل

func handler(err *error, handle func(error) error) {
  // nil handle is treated as the identity
  if *err != nil && handle != nil {
    *err = handle(*err)
  }
}

الذي قد تستخدمه مثل

defer handler(&err, func(err error) error {
  if errors.Is(err, io.EOF) {
    return nil
  }
  return fmt.Errorf("oops: %w", err)
})

يمكنك جعل handler نفسها شبه سحرية مدمجة مثل try .

إذا كان الأمر سحرًا ، فيمكن أن تأخذ حجةها الأولى ضمنيًا - السماح باستخدامها حتى في الوظائف التي لا تذكر عائدها error ، مما يؤدي إلى استبعاد أحد الجوانب الأقل حظًا في الاقتراح الحالي مع تقليله روائح وخطأ عرضة لتزيين الأخطاء. بالطبع ، هذا لا يقلل من المثال السابق كثيرًا:

defer handler(func(err error) error {
  if errors.Is(err, io.EOF) {
    return nil
  }
  return fmt.Errorf("oops: %w", err)
})

إذا كان الأمر سحريًا بهذه الطريقة ، فيجب أن يكون خطأ في وقت التجميع إذا تم استخدامه في أي مكان باستثناء الوسيطة لـ defer . يمكنك أن تخطو خطوة أبعد وتجعلها تؤجل ضمنيًا ، لكن defer handler يقرأ بشكل جيد جدًا.

نظرًا لأنه يستخدم defer ، يمكنه الاتصال بـ handle func كلما كان هناك خطأ غير معدوم يتم إرجاعه ، مما يجعله مفيدًا حتى بدون try حيث يمكنك إضافة

defer handler(wrapErrWithPackageName)

في الجزء العلوي إلى fmt.Errorf("mypkg: %w", err) كل شيء.

يمنحك هذا الكثير من عرض check / handle ولكنه يعمل مع التأجيل بشكل طبيعي (وبشكل صريح) مع التخلص من الحاجة ، في معظم الحالات ، لتسمية صراحة err عودة try إنه ماكرو مباشر نسبيًا (أتخيل) يمكن تنفيذه بالكامل في الواجهة الأمامية.

هذا ليس صحيحًا - في مسودة التصميم ، كل دالة تقوم بإرجاع خطأ لها معالج افتراضي يقوم بإرجاع الخطأ فقط.

يا سيئة ، أنت على صواب.

أعني أنني أعتقد أن المثال المعني هو 10٪ وليس 90٪. هذا التأكيد مطروح بالتأكيد للنقاش ، ويسعدني سماع الحجج المضادة. ولكن في النهاية سيتعين علينا رسم الخط في مكان ما ونقول "نعم ، لن تحاول المحاولة للتعامل مع هذه الحالة. سيتعين عليك استخدام أسلوب معالجة الأخطاء القديم. معذرة."

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

هل يمكن أن يقوم try() بالالتفاف التلقائي للأخطاء بسياق مفيد للتصحيح؟ على سبيل المثال ، إذا أصبح xerrors errors ، يجب أن تحتوي الأخطاء على شيء يشبه تتبع المكدس الذي يمكن أن يضيفه try() ، أليس كذلك؟ إذا كان الأمر كذلك ، فربما يكون ذلك كافياً 🤔

إذا كانت الأهداف (اقرأ https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md):

• القضاء على النمطي
• الحد الأدنى من التغييرات اللغوية
• تغطي "السيناريوهات الأكثر شيوعًا"
• إضافة القليل من التعقيد إلى اللغة

أود أن آخذ الاقتراح وأعطيه زاوية وأسمح بترحيل رمز "الخطوات الصغيرة" لجميع أسطر الشفرة المليارات من هناك.

بدلا من المقترح:

func printSum(a, b string) error {
        defer fmt.HandleErrorf(&err, "sum %s %s: %v", a,b, err) 
        x := try(strconv.Atoi(a))
        y := try(strconv.Atoi(b))
        fmt.Println("result:", x + y)
        return nil
}

نحن نقدر:

func printSum(a, b string) error {
        var err ErrHandler{HandleFunc : twoStringsErr("printSum",a,b)} 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        return nil
}

ماذا سنكسب؟
يمكن تضمين twoStringsErr للطباعة ، أو معالج عام يعرف كيفية التقاط الأخطاء (في هذه الحالة مع معلمتين من سلسلة) - لذلك إذا كان لدي نفس التواقيع الوظيفية المتكررة المستخدمة في العديد من وظائفي ، فلن أحتاج إلى إعادة كتابة كل معالج زمن
بالطريقة نفسها ، يمكنني تمديد نوع ErrHandler بالطريقة التالية:

type ioErrHandler ErrHandler
func (i ErrHandler) Handle() ...{

}

أو

type parseErrHandler ErrHandler
func (p parseErrHandler) Handle() ...{

}

أو

type str2IntErrHandler ErrHandler
func (s str2IntErrHandler) Handle() ...{

}

واستخدم هذا في جميع أنحاء الكود الخاص بي:

func printSum(a, b string) error {
        var pErr str2IntErrHandler 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        return nil
}

لذا ، فإن الحاجة الفعلية هي تطوير مشغل عندما يخطئ ، ويتم تعيين الخطأ على أنه لا شيء
باستخدام هذه الطريقة يمكننا أيضًا:

func (s str2IntErrHandler) Handle() bool{
   **return false**
}

والذي من شأنه أن يخبر وظيفة الاستدعاء بالاستمرار بدلاً من العودة

واستخدم معالجات أخطاء مختلفة في نفس الوظيفة:

func printSum(a, b string) error {
        var pErr str2IntErrHandler 
        var oErr overflowError 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        totalAsByte,oErr := sumBytes(x,y)
        sunAsByte,oErr := subtractBytes(x,y)
        return nil
}

إلخ.

تجاوز الأهداف مرة أخرى

• القضاء على المتداول - تم
• الحد الأدنى من التغييرات اللغوية - تم
• تغطي "السيناريوهات الأكثر شيوعًا" - أكثر من IMO المقترح
• إضافة القليل جدا من التعقيد للغة - وحي
  بالإضافة إلى - ترحيل رمز أسهل من

x, err := strconv.Atoi(a)

ل

x, err.Error := strconv.Atoi(a)

وفي الواقع - سهولة قراءة أفضل (IMO ، مرة أخرى)

guybrand أنت آخر ملتزم بهذا الموضوع المتكرر (الذي أحبه).

راجع https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

guybrand يبدو هذا اقتراحًا مختلفًا تمامًا ؛ أعتقد أنه يجب عليك تقديمه باعتباره مشكلته الخاصة حتى يتمكن هذا الشخص من التركيز على مناقشة اقتراح griesemer .

natefinch توافق. أعتقد أن هذا موجه أكثر نحو تحسين التجربة أثناء كتابة Go بدلاً من تحسين القراءة. أتساءل عما إذا كانت وحدات ماكرو IDE أو المقتطفات يمكنها حل المشكلة دون أن تصبح هذه ميزة للغة.

@نبيذ جيد

لنفترض أن التفاف الأخطاء بسياق مفيد يعد ممارسة جيدة ، فسيتم اعتبار try() ممارسة سيئة لأنه لا يضيف أي سياق. هذا يعني أن try() هي ميزة لا يرغب أحد في استخدامها وتصبح ميزة يتم استخدامها نادرًا جدًا لدرجة أنها قد لا تكون موجودة.

كما هو مذكور في الاقتراح (كما هو موضح بالمثال) ، لا يمنعك try بشكل أساسي من إضافة سياق. أود أن أقول إن الطريقة التي يُقترح بها ، إضافة سياق إلى الأخطاء متعامدة تمامًا معها. يتم تناول هذا بشكل خاص في الأسئلة الشائعة الخاصة بالاقتراح.

أدرك أن try لن يكون مفيدًا إذا كان ضمن دالة واحدة إذا كان هناك العديد من السياقات المختلفة التي تريد إضافتها إلى أخطاء مختلفة من استدعاءات الوظائف. ومع ذلك ، أعتقد أيضًا أن شيئًا ما في السياق العام HandleErrorf يغطي مساحة كبيرة من الاستخدام لأن إضافة سياق على مستوى الوظيفة فقط إلى الأخطاء ليس بالأمر غير المعتاد.

بدلاً من مجرد قول "حسنًا ، إذا لم تعجبك ، فلا تستخدمه وتصمت" (هذه هي الطريقة التي تقرأ بها) ، أعتقد أنه سيكون من الأفضل محاولة معالجة ما يفكر فيه كثير من الاستخدامات في وجود خطأ في التصميم.

إذا كانت هذه هي الطريقة التي تقرأ بها أعتذر. وجهة نظري ليست أنه يجب عليك التظاهر بأنه غير موجود إذا لم يعجبك. من الواضح أن هناك حالات يكون فيها try غير مجدية وأنه لا يجب عليك استخدامها في مثل هذه الحالات ، والتي أعتقد بالنسبة لهذا الاقتراح أنها تحقق توازنًا جيدًا بين KISS والمنفعة العامة. لم أكن أعتقد أنني لم أكن واضحًا بشأن هذه النقطة.

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

0) على الجانب الإيجابي ، عبرrasky وadg و eandre و @ dpinela وآخرين صراحةً عن سعادتهم لتبسيط الكود الذي يوفره try .

1) يبدو أن الشاغل الأكثر أهمية هو أن try لا يشجع أسلوب معالجة الأخطاء بشكل جيد ولكنه بدلاً من ذلك يروج "للخروج السريع". ( agnivade و @ peterbourgon و @ politician و @ a8m و eandre و prologic و @ kungfusheep و @ cpuguy وآخرين أعربوا عن قلقهم حيال ذلك.)

2) كثير من الناس لا يحبون فكرة المضمنة ، أو بناء جملة الوظيفة التي تأتي معها لأنها تخفي return . سيكون من الأفضل استخدام كلمة رئيسية. ( sheerun ، Redundancy،dolmen، @ komuw،RobertGrantEllis ، @ elagergren -spideroak). يمكن أيضًا التغاضي عن try بسهولة (@ peterbourgon) ، خاصةً لأنه يمكن أن يظهر في التعبيرات التي قد تكون متداخلة بشكل عشوائي. تشعر natefinch بالقلق من أن try يجعل الأمر "سهلًا للغاية لإلقاء الكثير في سطر واحد" ، وهو أمر نحاول عادةً تجنبه في Go. أيضًا ، قد لا يكون دعم IDE للتأكيد على try كافيًا (dominikh) ؛ يحتاج try إلى "الوقوف بمفرده".

3) بالنسبة للبعض ، فإن الوضع الراهن لبيانات if الصريحة ليست مشكلة ، فهم سعداء بها ( bitfield ، @ marwan-at-work،natefinch). من الأفضل أن يكون لديك طريقة واحدة فقط للقيام بالأشياء (gbbr) ؛ وبيانات if الصريحة أفضل من العبارات الضمنية return ( DavexPro ، hmage ، prologic ،natefinch).
على نفس المنوال ، فإنmattn تشعر بالقلق إزاء "الربط الضمني" لنتيجة الخطأ try - الاتصال غير مرئي بشكل واضح في الكود.

4) استخدام try سيجعل من الصعب تصحيح التعليمات البرمجية ؛ على سبيل المثال ، قد يكون من الضروري إعادة كتابة تعبير try مرة أخرى في عبارة if فقط حتى يمكن إدراج عبارات التصحيح ( deanveloper ، typeless ، @ networkimprov ، آخرون).

5) هناك بعض القلق بشأن استخدام المرتجعات المسماة ( buchanae ،adg).

قدم العديد من الأشخاص اقتراحات لتحسين أو تعديل الاقتراح:

6) اختار البعض فكرة معالج الأخطاء الاختياري (beoran) أو سلسلة التنسيق المقدمة إلى try ( unexge ، @ a8m ، eandre ،gotwarlost) لتشجيع المعالجة الجيدة للأخطاء.

7) اقترح pierrec أن gofmt يمكنه تنسيق تعبيرات try بشكل مناسب لجعلها أكثر وضوحًا.
بدلاً من ذلك ، يمكن للمرء أن يجعل الكود الموجود أكثر ضغطًا من خلال السماح لـ gofmt بتنسيق كشوفات حساب if للتحقق من وجود أخطاء في سطر واحد (zeebo).

8) يجادل @ marwan-at-work بأن try ينقل ببساطة معالجة الأخطاء من عبارات $ # $ if try . بدلاً من ذلك ، إذا أردنا حل المشكلة فعليًا ، يجب على Go "امتلاك" معالجة الأخطاء بجعلها ضمنية حقًا. يجب أن يكون الهدف هو جعل معالجة الأخطاء (المناسبة) أبسط وجعل المطورين أكثر إنتاجية (cpuguy).

9) أخيرًا ، لا يحب بعض الأشخاص الاسم try ( beoran ، HiImJC ،dolmen) أو يفضلون رمزًا مثل ? ( @ twisted1919، leaxoy ، آخرون) .

بعض التعليقات على هذه التعليقات (مرقمة وفقًا لذلك):

0) شكرا لردود الفعل الإيجابية! :-)

1) سيكون من الجيد معرفة المزيد عن هذا القلق. إن أسلوب الترميز الحالي الذي يستخدم عبارات if لاختبار الأخطاء واضح بقدر ما يمكن أن يكون. من السهل جدًا إضافة معلومات إضافية إلى الخطأ ، على أساس فردي (لكل if ). غالبًا ما يكون من المنطقي معالجة جميع الأخطاء المكتشفة في دالة بطريقة موحدة ، والتي يمكن إجراؤها باستخدام defer - وهذا ممكن بالفعل الآن. إنها حقيقة أننا نمتلك بالفعل جميع الأدوات للتعامل مع الأخطاء بشكل جيد في اللغة ، وأن مشكلة بنية المعالج التي لا تكون متعامدة مع defer ، هي التي دفعتنا إلى ترك آلية جديدة لزيادة الأخطاء فقط. .

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

3) سبب هذا الاقتراح هو أن معالجة الأخطاء (على وجه التحديد الكود المعياري المرتبط) قد تم ذكرها كمسألة مهمة في Go (بجانب نقص الأدوية العامة) من قبل مجتمع Go. هذا الاقتراح يعالج بشكل مباشر القلق المعياري. إنها لا تفعل أكثر من حل الحالة الأساسية لأن أي حالة أكثر تعقيدًا يتم التعامل معها بشكل أفضل مع ما لدينا بالفعل. لذلك ، في حين أن عددًا كبيرًا من الأشخاص سعداء بالوضع الراهن ، هناك (ربما) مجموعة كبيرة بنفس القدر من الأشخاص الذين يرغبون في اتباع نهج أكثر بساطة مثل try ، مدركين جيدًا أن هذا "عادل" التجميل اللغوى.

4) نقطة التصحيح هي مصدر قلق صحيح. إذا كانت هناك حاجة لإضافة رمز بين اكتشاف خطأ و return ، فإن الاضطرار إلى إعادة كتابة تعبير try في عبارة if قد يكون أمرًا مزعجًا.

5) قيم الإرجاع المسماة: الوثيقة التفصيلية تناقش هذا باستفاضة. إذا كان هذا هو مصدر القلق الرئيسي بشأن هذا الاقتراح ، فأنا أعتقد أننا في وضع جيد.

6) وسيطة المعالج الاختيارية لـ try : الوثيقة التفصيلية تناقش هذا أيضًا. انظر قسم تكرارات التصميم.

7) استخدام gofmt لتنسيق تعبيرات try بحيث تكون مرئية بشكل إضافي سيكون بالتأكيد خيارًا. ولكنه قد ينتقص من بعض مزايا try عند استخدامه في تعبير.

8) لقد نظرنا في النظر إلى المشكلة من وجهة نظر معالجة الخطأ ( handle ) وليس من وجهة نظر اختبار الخطأ ( try ). على وجه التحديد ، نظرنا بإيجاز فقط في تقديم مفهوم معالج الأخطاء (على غرار مسودة التصميم الأصلية المقدمة في Gophercon العام الماضي). كان التفكير هو أنه إذا (وفقط إذا) تم التصريح عن معالج ، في تعيينات متعددة القيم حيث تكون القيمة الأخيرة من النوع error ، يمكن ببساطة ترك هذه القيمة بعيدًا في مهمة. سيتحقق المترجم ضمنيًا مما إذا كان لا شيء ، وإذا كان الأمر كذلك ، يتفرع إلى المعالج. هذا من شأنه أن يجعل معالجة الأخطاء الصريحة تختفي تمامًا ويشجع الجميع على كتابة معالج بدلاً من ذلك. بدا هذا وكأنه نهج متطرف لأنه سيكون ضمنيًا تمامًا - حقيقة أن الشيك يحدث سيكون غير مرئي.

9) هل لي أن أقترح ألا نتخلى عن الاسم بالدراجة في هذه المرحلة. بمجرد تسوية جميع المخاوف الأخرى ، يكون الوقت أفضل لضبط الاسم.

هذا لا يعني أن المخاوف غير صحيحة - فالردود أعلاه توضح ببساطة تفكيرنا الحالي. للمضي قدمًا ، سيكون من الجيد التعليق على مخاوف جديدة (أو أدلة جديدة تدعم هذه المخاوف) - مجرد إعادة ذكر ما قيل بالفعل لا يوفر لنا مزيدًا من المعلومات.

وأخيرًا ، يبدو أن ليس كل من علق على القضية قد قرأ المستند التفصيلي. يرجى القيام بذلك قبل التعليق لتجنب تكرار ما قيل بالفعل. شكرا.

هذا ليس تعليقًا على الاقتراح ، ولكنه تقرير خطأ مطبعي. لم يتم إصلاحه منذ نشر الاقتراح الكامل ، لذلك اعتقدت أنني سأذكره:

func try(t1 T1, t1 T2, … tn Tn, te error) (T1, T2, … Tn)

يجب ان يكون:

func try(t1 T1, t2 T2, … tn Tn, te error) (T1, T2, … Tn)

هل سيكون من المفيد تحليل كود Go المتاح علنًا لبيانات التحقق من الأخطاء لمحاولة اكتشاف ما إذا كانت معظم عمليات التحقق من الأخطاء متكررة حقًا أو إذا كانت عمليات التحقق المتعددة في نفس الوظيفة تضيف معلومات سياقية مختلفة في معظم الحالات؟ سيكون الاقتراح منطقيًا للغاية بالنسبة للحالة الأولى ولكنه لن يساعد الحالة الثانية. في الحالة الأخيرة ، سيستمر الأشخاص في استخدام if err != nil أو التخلي عن إضافة سياق إضافي ، واستخدام try() واللجوء إلى إضافة سياق خطأ شائع لكل دالة والتي قد تكون IMO ضارة. مع ميزات قيم الخطأ القادمة ، أعتقد أننا نتوقع أن يقوم الأشخاص بتغليف الأخطاء بمزيد من المعلومات في كثير من الأحيان. ربما أساءت فهم الاقتراح ولكن AFAIU ، هذا يساعد في تقليل النموذج المعياري فقط عندما يجب تغليف جميع الأخطاء من وظيفة واحدة بطريقة واحدة بالضبط ولا يساعد إذا كانت الوظيفة تتعامل مع خمسة أخطاء قد تحتاج إلى لفها بشكل مختلف. لست متأكدًا من مدى شيوع مثل هذه الحالات في البرية (شائعة جدًا في معظم مشاريعي) ولكني قلق من أن try() قد يشجع الناس على استخدام أغلفة شائعة لكل وظيفة حتى عندما يكون من المنطقي التفاف أخطاء مختلفة بشكل مختلف.

مجرد تعليق سريع مدعوم ببيانات مجموعة عينة صغيرة:

نقترح وظيفة مضمنة جديدة تسمى try ، مصممة خصيصًا للتخلص من الصيغة المعيارية إذا كانت العبارات مرتبطة عادةً بمعالجة الأخطاء في Go

Iff هذه هي المشكلة الأساسية التي يتم حلها من خلال هذا الاقتراح ، أجد أن هذا "النموذج المعياري" لا يمثل سوى 1.4٪ من الكود الخاص بي عبر العشرات من المشاريع مفتوحة المصدر المتاحة للجمهور والتي يبلغ مجموعها حوالي 60 ألفًا من SLOC.

هل تشعر بالفضول إذا كان لدى أي شخص آخر نفس الإحصائيات؟

في قاعدة بيانات أكبر بكثير مثل Go نفسها والتي يبلغ مجموعها حوالي 1.6M SLOC ، يصل هذا إلى حوالي 0.5 ٪ من قاعدة الشفرة التي تحتوي على خطوط مثل if err != nil .

هل هذه حقًا هي المشكلة الأكثر تأثيرًا التي يجب حلها باستخدام Go 2؟

شكرًا جزيلاً لك griesemer على قضاء الوقت في استعراض أفكار الجميع وتقديم الأفكار بشكل صريح. أعتقد أنه يساعد حقًا في إدراك أن المجتمع يُسمع في هذه العملية.

1. اقترح pierrec أنه يمكن لـ gofmt تنسيق تجربة التعبيرات بشكل مناسب لجعلها أكثر وضوحًا.
   بدلاً من ذلك ، يمكن للمرء أن يجعل الكود الحالي أكثر إحكاما من خلال السماح لـ gofmt بتنسيق عبارات if للتحقق من الأخطاء في سطر واحد (zeebo).

1. سيكون استخدام gofmt لتنسيق تعبيرات try بحيث تكون مرئية بشكل إضافي خيارًا بالتأكيد. ولكنه قد ينتقص من بعض مزايا try عند استخدامه في تعبير.

هذه أفكار قيّمة حول طلب gofmt لتنسيق try ، لكنني مهتم إذا كانت هناك أي أفكار على وجه الخصوص حول gofmt السماح بفحص كشف الحساب if أن يكون الخطأ سطرًا واحدًا. تم تجميع العرض بتنسيق try ، لكنني أعتقد أنه شيء متعامد تمامًا. شكرا.

griesemer أشكرك على العمل الرائع من خلال جميع التعليقات والإجابة على معظم التعليقات إن لم يكن كلها 🎉

هناك شيء واحد لم يتم تناوله في ملاحظاتك وهو فكرة استخدام جزء الأدوات / الفحص من لغة Go لتحسين تجربة معالجة الأخطاء ، بدلاً من تحديث بناء جملة Go.

على سبيل المثال ، مع هبوط LSP الجديد ( gopls ) ، يبدو أنه مكان مثالي لتحليل توقيع الوظيفة والعناية بأخطاء معالجة الأخطاء للمطور ، مع التفاف وفحص مناسبين أيضًا.

griesemer أنا متأكد من أن هذا لم يتم التفكير فيه جيدًا ، لكنني حاولت تعديل اقتراحك أقرب إلى شيء سأكون مرتاحًا له هنا: https://www.reddit.com/r/golang/comments/bwvyhe / offer_a_builtin_go_error_check_function_try / eq22bqa؟ utm_source = share & utm_medium = web2x

zeebo سيكون من السهل إنشاء تنسيق $ gofmt if err != nil { return ...., err } على سطر واحد. من المفترض أنه سيكون فقط لهذا النوع المحدد من نمط if ، وليس كل كشوف الحساب "القصيرة" if ؟

على نفس المنوال ، كانت هناك مخاوف من أن يكون try غير مرئي لأنه على نفس السطر مثل منطق الأعمال. لدينا كل هذه الخيارات:

النمط الحالي:

a, b, c, ... err := BusinessLogic(...)
if err != nil {
   return ..., err
}

سطر واحد if :

a, b, c, ... err := BusinessLogic(...)
if err != nil { return ..., err }

try في سطر منفصل (!):

a, b, c, ... err := BusinessLogic(...)
try(err)

try كما هو مقترح:

a, b, c := try(BusinessLogic(...))

يبدو السطر الأول والأخير هو الأكثر وضوحًا (بالنسبة لي) ، خاصةً بمجرد استخدام أحدهما للتعرف على try على أنه ما هو عليه. مع السطر الأخير ، يتم التحقق من الخطأ بشكل صريح ، ولكن نظرًا لأنه (عادةً) ليس الإجراء الرئيسي ، فهو أكثر قليلاً في الخلفية.

@ marwan-at-work لست متأكدًا مما تقترحه من أن الأدوات مناسبة لك. هل تقترح عليهم إخفاء معالجة الخطأ بطريقة ما؟

تضمين التغريدة

guybrand يبدو هذا اقتراحًا مختلفًا تمامًا ؛ أعتقد أنه يجب عليك تقديمه باعتباره مشكلته الخاصة حتى يتمكن هذا الشخص من التركيز على مناقشة اقتراح griesemer .

IMO اقتراحي يختلف فقط في بناء الجملة ، وهذا يعني:

• الأهداف متشابهة في المحتوى والأولوية.
• تتشابه فكرة التقاط كل خطأ ضمن السطر الخاص به وبالتالي (إن لم يكن لا شيء) للخروج من الوظيفة أثناء المرور عبر دالة معالج (pseudo asm - إنها "jnz" و "call").
• هذا يعني أيضًا أن عدد الخطوط في جسم الوظيفة (بدون المؤجل) والتدفق سيبدو متشابهين تمامًا (وبالتالي من المحتمل أن يتحول AST إلى نفس الشيء أيضًا)

لذا فإن الفرق الرئيسي هو ما إذا كنا نلف استدعاء الوظيفة الأصلي بـ try (func ()) الذي سيحلل دائمًا var الأخير إلى jnz المكالمة أو نستخدم قيمة الإرجاع الفعلية للقيام بذلك.

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

ومع ذلك ، أفكر بجدية في كتابة اقتراح ، شكرًا على الفكرة.

تضمين التغريدة

لست متأكدًا مما تقترحه من أن الأدوات مناسبة لك. هل تقترح عليهم إخفاء معالجة الخطأ بطريقة ما؟

العكس تمامًا: أقترح أن gopls يمكنه اختياريًا كتابة الخطأ الذي يعالج النموذج المعياري لك.

كما ذكرت في تعليقك الأخير:

سبب هذا الاقتراح هو أن معالجة الأخطاء (على وجه التحديد الرمز المعياري المرتبط) قد تم ذكرها كمسألة مهمة في Go (بجانب نقص الأدوية العامة) من قبل مجتمع Go

لذا فإن جوهر المشكلة هو أن المبرمج ينتهي بكتابة الكثير من التعليمات البرمجية المعيارية. لذا فإن القضية تتعلق بالكتابة وليس القراءة. لذلك ، اقتراحي هو: دع الكمبيوتر (الأدوات / gopls) يقوم بالكتابة للمبرمج عن طريق تحليل توقيع الوظيفة ووضع شروط معالجة الأخطاء المناسبة.

علي سبيل المثال:

// user begins to write this function: 
func openFile(path string) ([]byte, error) {
  file, err := os.Open(path)
  defer file.Close()
  bts, err := ioutil.ReadAll(file)
  return bts, nil
}

ثم يقوم المستخدم بتشغيل الأداة ، ربما فقط عن طريق حفظ الملف (على غرار طريقة عمل gofmt / goimports عادةً) وسيقوم gopls بالنظر في هذه الوظيفة ، وتحليل توقيع الإرجاع الخاص به وزيادة الرمز ليكون هذا:

// user has triggered the tool (by saving the file, or code action)
func openFile(path string) ([]byte, error) {
  file, err := os.Open(path)
  if err != nil {
    return nil, fmt.Errorf("openFile: %w", err)
  }
  defer file.Close()
  bts, err := ioutil.ReadAll(file)
  if err != nil {
    return nil, fmt.Errorf("openFile: %w", err)
  }
  return bts, nil
}

بهذه الطريقة ، نحصل على أفضل ما في العالمين: نحصل على سهولة القراءة / الوضوح لنظام معالجة الأخطاء الحالي ، ولم يكتب المبرمج أي خطأ في معالجة النموذج المعياري. والأفضل من ذلك ، يمكن للمستخدم المضي قدمًا وتعديل كتل معالجة الأخطاء لاحقًا للقيام بسلوك مختلف: يمكن أن يفهم gopls أن الكتلة موجودة ، ولن تقوم بتعديلها.

كيف تعرف الأداة أنني أنوي التعامل مع err لاحقًا في الوظيفة بدلاً من العودة مبكرًا؟ وإن كان ذلك نادرًا ، لكن رمزًا كتبته مع ذلك.

أعتذر إذا تم طرح هذا من قبل ، لكن لم أجد أي ذكر له.

try(DoSomething()) يقرأ جيدًا بالنسبة لي ، وهو أمر منطقي: الكود يحاول فعل شيء ما. يشعر try(err) ، OTOH ، بالارتياح قليلاً ، من حيث المعنى: كيف يمكن للمرء تجربة الخطأ؟ في رأيي ، يمكن للمرء _ اختبار_ أو _ التحقق من_ خطأ ، ولكن _ المحاولة_ لا يبدو أنه صحيح.

إنني أدرك أن السماح بـ try(err) مهم لأسباب تتعلق بالاتساق: أفترض أنه سيكون من الغريب أن يعمل try(DoSomething()) ، لكن err := DoSomething(); try(err) لم ينجح. ومع ذلك ، يبدو أن try(err) يبدو محرجًا بعض الشيء على الصفحة. لا يمكنني التفكير في أي وظائف مضمنة أخرى يمكن جعلها تبدو غريبة بهذه السهولة.

ليس لدي أي اقتراحات محددة بشأن هذا الموضوع ، لكنني مع ذلك أردت أن أبدي هذه الملاحظة.

تضمين التغريدة في الواقع ، كان الاقتراح يجب أن يكون مقابل return فقط ، لكنني أظن أن السماح لأي عبارة واحدة بأن تكون سطرًا واحدًا سيكون أمرًا جيدًا. على سبيل المثال ، في الاختبار ، يمكن للمرء ، دون أي تغييرات في مكتبة الاختبار ، أن يكون لديه

if err != nil { t.Fatal(err) }

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

مع السطر الأخير ، يتم إخفاء بعض التكلفة. إذا كنت ترغب في وضع تعليق توضيحي على الخطأ ، والذي أعتقد أن المجتمع قاله بصوت عالٍ إنه أفضل الممارسات المرغوبة ويجب تشجيعه ، فسيتعين على المرء تغيير توقيع الوظيفة لتسمية الحجج ويأمل أن يتم تطبيق defer واحد على كل خروج في جسم الوظيفة ، وإلا فإن try ليس له قيمة ؛ ربما سلبية بسبب سهولة.

ليس لدي المزيد لأضيفه أنني أعتقد أنه لم يُقال بالفعل.

لم أرَ كيف أجيب على هذا السؤال من مستند التصميم. ماذا يفعل هذا الرمز:

func foo() (err error) {
    src := try(getReader())
    if src != nil {
        n, err := src.Read(nil)
        if err == io.EOF {
            return nil
        }
        try(err)
        println(n)
    }
    return nil
}

ما أفهمه هو أنه سيتم إلغاء الأمر

func foo() (err error) {
    tsrc, te := getReader()
    if err != nil {
        err = te
        return
    }
    src := tsrc

    if src != nil {
        n, err := src.Read(nil)
        if err == io.EOF {
            return nil
        }

        terr := err
        if terr != nil {
            err = terr
            return
        }

        println(n)
    }
    return nil
}

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

@ marwan-at-work

كما ذكرت في تعليقك الأخير:

سبب هذا الاقتراح هو أن معالجة الأخطاء (على وجه التحديد الرمز المعياري المرتبط) قد تم ذكرها كمسألة مهمة في Go (بجانب نقص الأدوية العامة) من قبل مجتمع Go

لذا فإن جوهر المشكلة هو أن المبرمج ينتهي بكتابة الكثير من التعليمات البرمجية المعيارية. لذا فإن القضية تتعلق بالكتابة وليس القراءة.

أعتقد أن الأمر في الواقع هو العكس تمامًا - بالنسبة لي ، فإن أكبر إزعاج من الخطأ الحالي في معالجة النموذج المعياري ليس الاضطرار إلى كتابته كثيرًا ، بل كيف ينثر المسار السعيد للوظيفة عموديًا عبر الشاشة ، مما يجعل من الصعب فهمه عند ومضة. يظهر التأثير بشكل خاص في كود الإدخال / الإخراج الثقيل ، حيث يوجد عادةً كتلة من الصيغة المعيارية بين كل عمليتين. حتى الإصدار المبسط من CopyFile يأخذ 20 سطرًا تقريبًا على الرغم من أنه لا يؤدي سوى خمس خطوات: المصدر المفتوح ، وتأجيل إغلاق المصدر ، والوجهة المفتوحة ، ونسخ المصدر -> الوجهة ، وإغلاق الوجهة.

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

أحب try على سطر منفصل.
وآمل أن تحدد وظيفة handler بشكل مستقل.

func try(error, optional func(error)error)

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    try(err)

    handle := func(err error) error {
        tx.Rollback()
        return err
    }

    var res int64
    _, err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    try(err, handle)

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    try(err, handle)

    return tx.Commit()
}

zeebo : الأمثلة التي قدمتها هي ترجمة 1: 1. الأول (التقليدي if ) لم يعالج الخطأ ، وكذلك الآخرون. إذا كان أول من تعامل مع الخطأ ، وإذا كان هذا هو المكان الوحيد الذي يتم فيه التحقق من الخطأ في دالة ، فقد يكون المثال الأول (باستخدام if ) هو الخيار المناسب لكتابة الكود. إذا كان هناك العديد من عمليات التحقق من الأخطاء ، وكلها تستخدم نفس معالجة الأخطاء (التفاف) ، على سبيل المثال لأنها تضيف جميعًا معلومات حول الوظيفة الحالية ، يمكن للمرء استخدام عبارة defer للتعامل مع الأخطاء كلها في مكان واحد. اختياريًا ، يمكن للمرء إعادة كتابة if في try 's (أو تركهم وشأنهم). إذا كان هناك العديد من الأخطاء التي يجب التحقق منها ، وجميعهم يتعاملون مع الأخطاء بشكل مختلف (والذي قد يكون علامة على أن اهتمام الوظيفة واسع جدًا وأنه قد يلزم تقسيمها) ، فإن استخدام if 's هو الطريق للذهاب. نعم ، هناك أكثر من طريقة لفعل الشيء نفسه ، والاختيار الصحيح يعتمد على الكود وكذلك على الذوق الشخصي. بينما نسعى جاهدين في Go من أجل "طريقة واحدة للقيام بشيء واحد" ، فإن هذا بالطبع ليس هو الحال بالفعل ، خاصة بالنسبة للبنى المشتركة. على سبيل المثال ، عندما يصبح التسلسل if - else - if طويلًا جدًا ، أحيانًا يكون switch أكثر ملاءمة. في بعض الأحيان ، يعبر إعلان المتغير var x int عن النية بشكل أفضل من x := 0 ، وهكذا دواليك (على الرغم من أن هذا لا يسعد الجميع).

فيما يتعلق بسؤالك حول "إعادة الكتابة": لا ، لن يكون هناك خطأ في التجميع. لاحظ أن إعادة الكتابة تحدث داخليًا (وقد تكون أكثر كفاءة مما يوحي به نمط الكود) ، ولا داعي للمترجم للشكوى من عودة مظللة. في المثال الخاص بك ، قمت بتحديد متغير err محلي في نطاق متداخل. سيظل بإمكان try الوصول المباشر إلى المتغير err بالطبع. قد تبدو إعادة الكتابة أكثر مثل هذا تحت الأغطية.

[محرر] ملاحظة: أفضل إجابة هي: try ليست عودة عارية (على الرغم من أن إعادة الكتابة تبدو مثلها). بعد كل شيء ، يعطي المرء صراحة try وسيطة تحتوي (أو) الخطأ الذي تم إرجاعه إذا لم يكن nil . خطأ الظل للعوائد المجردة هو خطأ في المصدر (وليس الترجمة الأساسية للمصدر. لا يحتاج المترجم إلى الخطأ.

إذا لم يكن نوع الإرجاع النهائي للوظيفة الشاملة من نوع الخطأ ، فهل يمكننا الذعر؟

سيجعل الجهاز المدمج أكثر تنوعًا (مثل إرضاء قلقي في # 32219)

pjebs تم النظر في هذا واتخاذ قرار ضده. يرجى قراءة مستند التصميم التفصيلي (الذي يشير صراحة إلى مشكلتك في هذا الموضوع).

أريد أيضًا أن أشير إلى أن try () يتم التعامل معه كتعبير ، على الرغم من أنه يعمل كعبارة إرجاع. نعم ، أعلم أن المحاولة مبنية على الماكرو ولكن معظم المستخدمين سيستخدمون هذا مثل البرمجة الوظيفية ، على ما أعتقد.

func doSomething() (error, error, error, error, error) {
   ...
}

try(try(try(try(try(doSomething)))))

يقول التصميم أنك استكشفت استخدام panic بدلاً من العودة مع الخطأ.

أنا ألقي الضوء على اختلاف دقيق:

افعل بالضبط ما ينص عليه اقتراحك الحالي ، باستثناء إزالة القيود التي يجب أن تحتوي الوظيفة الشاملة على نوع إرجاع نهائي من النوع error .

إذا لم يكن نوع الإرجاع النهائي error => الذعر
إذا كنت تستخدم إعلانات المتغير على مستوى الحزمة => الذعر (يزيل الحاجة إلى اصطلاح MustXXX( ) )

بالنسبة لاختبارات الوحدة ، تغيير متواضع في اللغة.

mattn ، أشك بشدة في أن أي عدد كبير من الأشخاص سيكتب رمزًا من هذا القبيل.

pjebs ، تلك الدلالات - الذعر إذا لم يكن هناك خطأ ينتج عن الوظيفة الحالية - هو بالضبط ما يناقشه مستند التصميم في https://github.com/golang/proposal/blob/master/design/32437-try-builtin. مناقشة.

علاوة على ذلك ، في محاولة لجعل المحاولة مفيدة ليس فقط داخل الوظائف مع نتيجة خطأ ، تعتمد دلالات المحاولة على السياق: إذا تم استخدام المحاولة على مستوى الحزمة ، أو إذا تم استدعاؤها داخل دالة بدون نتيجة خطأ ، حاول الذعر عند مواجهة خطأ. (جانبا ، بسبب هذه الخاصية ، تم استدعاء المضمن يجب بدلاً من المحاولة في هذا الاقتراح.) يبدو أن المحاولة (أو يجب) التصرف بهذه الطريقة الحساسة للسياق أمرًا طبيعيًا ومفيدًا أيضًا: سيسمح بإلغاء العديد من الوظائف المساعدة المعرفة من قبل المستخدم المستخدمة حاليًا في تعبيرات التهيئة المتغيرة على مستوى الحزمة. سيفتح أيضًا إمكانية استخدام اختبارات الوحدة التجريبية عبر حزمة الاختبار.

ومع ذلك ، تم اعتبار حساسية السياق الخاصة بالمحاولة محفوفة بالمخاطر: على سبيل المثال ، يمكن أن يتغير سلوك الوظيفة التي تحتوي على استدعاءات المحاولة بصمت (من احتمال الذعر إلى عدم الذعر ، والعكس صحيح) إذا تمت إضافة نتيجة خطأ أو إزالتها من التوقيع. بدت هذه الخاصية خطيرة للغاية. كان الحل الواضح هو تقسيم وظيفة المحاولة إلى وظيفتين منفصلتين ، يجب أن تجربهما (تشبه إلى حد بعيد ما اقترحته المشكلة رقم 31442). لكن هذا كان سيتطلب وظيفتين مدمجتين جديدتين ، مع محاولة الاتصال المباشر فقط بالحاجة الفورية لدعم معالجة الأخطاء بشكل أفضل.

pjebs هذا _ بالضبط _ ما رأيناه في اقتراح سابق (انظر المستند التفصيلي ، قسم تكرارات التصميم ، الفقرة الرابعة):

علاوة على ذلك ، في محاولة لجعل المحاولة مفيدة ليس فقط داخل الوظائف مع نتيجة خطأ ، تعتمد دلالات المحاولة على السياق: إذا تم استخدام المحاولة على مستوى الحزمة ، أو إذا تم استدعاؤها داخل دالة بدون نتيجة خطأ ، حاول الذعر عند مواجهة خطأ. (جانبا ، بسبب تلك الخاصية ، تم استدعاء المضمن يجب بدلاً من المحاولة في هذا الاقتراح.)

كان الإجماع (الداخلي لفريق Go Team) هو أنه سيكون من try أن تعتمد على السياق وتتصرف بشكل مختلف تمامًا. على سبيل المثال ، يمكن أن تؤدي إضافة نتيجة خطأ إلى وظيفة (أو إزالتها) إلى تغيير سلوك الوظيفة بصمت من الذعر إلى عدم الذعر (أو العكس).

griesemer شكرًا على التوضيح حول إعادة الكتابة. أنا سعيد لأنه سيتم تجميعها.

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

حول الاضطرار إلى التعامل مع الأخطاء بشكل مختلف ، لا أوافق على أنها علامة على أن اهتمام الوظيفة واسع جدًا. لقد كنت أترجم بعض الأمثلة على الكود الحقيقي المطالب به من التعليقات وأضعها في قائمة منسدلة أسفل تعليقي الأصلي ، والمثال في https://github.com/golang/go/issues/32437#issuecomment - 499007288 أعتقد أنه يوضح حالة شائعة بشكل جيد:

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil { return nil, errors.WithMessage(err, "load config dir") }

    b := bytes.NewBuffer(nil)
    err = templates.ExecuteTemplate(b, "main", c)
    if err != nil { return nil, errors.WithMessage(err, "execute main template") }

    buf, err := format.Source(b.Bytes())
    if err != nil { return nil, errors.WithMessage(err, "format main template") }

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    err = ioutil.WriteFile(target, buf, 0644)
    if err != nil { return nil, errors.WithMessagef(err, "write file %s", target) }
    // ...
}

الغرض من هذه الوظيفة هو تنفيذ قالب على بعض البيانات في ملف. لا أعتقد أنه يجب تقسيمها ، وسيكون من المؤسف أن كل هذه الأخطاء قد اكتسبت للتو السطر الذي تم إنشاؤه بناءً عليه من إرجاء. قد يكون هذا مناسبًا للمطورين ، لكنه أقل فائدة للمستخدمين.

أعتقد أنه أيضًا إشارة إلى مدى دقة أخطاء defer wrap(&err, "message: %v", err) وكيف تعثروا حتى مع مبرمجي Go ذوي الخبرة.

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

griesemer آسف لقد قرأت قسمًا مختلفًا ناقش الذعر ولم أشاهد مناقشة المخاطر.

zeebo شكرا على هذا المثال. يبدو أن استخدام عبارة if هو الخيار الصحيح تمامًا في هذه الحالة. لكن النقطة المأخوذة ، قد يؤدي تنسيق if إلى سطر واحد إلى تبسيط هذا قليلاً.

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

file := try(os.Open("my_file.txt"), nil)

ماذا يجب أن يحدث إذا تم توفير المعالج ولكنه لا شيء؟ هل يجب محاولة الذعر أو التعامل معه على أنه معالج أخطاء غائب؟

كما هو مذكور أعلاه ، سيتصرف try وفقًا للاقتراح الأصلي. لن يكون هناك شيء مثل معالج الأخطاء الغائب ، فقط لا شيء.

ماذا لو تم استدعاء المعالج بخطأ غير صفري ثم قام بإرجاع نتيجة صفرية؟ هل هذا يعني أن الخطأ "ملغى"؟ أم يجب أن تعود وظيفة التضمين بخطأ لا شيء؟

أعتقد أن وظيفة التضمين ستعود مع وجود خطأ صفري. قد يكون الأمر محيرًا للغاية إذا كان بإمكان try متابعة التنفيذ أحيانًا حتى بعد تلقيه قيمة خطأ غير صفرية. سيسمح هذا للمعالجات بـ "الاهتمام" بالخطأ في بعض الظروف. قد يكون هذا السلوك مفيدًا في دالة نمط "get or create" ، على سبيل المثال.

func getOrCreateObject(obj *object) error {
    defaultObjectHandler := func(err error) error {
        if err == ObjectDoesNotExistErr {
            *obj = object{}
            return nil
        }
        return fmt.Errorf("getting or creating object: %v", err)
    }

    *obj = try(db.getObject(), defaultObjectHandler)
}

ولم يكن واضحًا أيضًا ما إذا كان السماح بمعالج أخطاء اختياري سيؤدي إلى تجاهل المبرمجين لمعالجة الأخطاء بشكل كامل. سيكون من السهل أيضًا إجراء معالجة مناسبة للأخطاء في كل مكان ولكن تفوت أي محاولة. وهكذا دواليك.

أعتقد أن كلا من هذه المخاوف يتم تخفيفها من خلال جعل المعالج حجة مطلوبة وغير قابلة للتشغيل. يتطلب من المبرمجين اتخاذ قرار واعي وصريح بأنهم لن يتعاملوا مع أخطائهم.

كمكافأة ، أعتقد أن طلب معالج الأخطاء لا يشجع أيضًا try s المتداخلة بشدة لأنها أقل إيجازًا. قد يرى البعض في هذا جانبًا سلبيًا ، لكنني أعتقد أنه مفيد.

velovix أحب الفكرة ، لكن لماذا يجب أن يكون معالج الأخطاء مطلوبًا؟ ألا يمكن أن يكون nil افتراضيًا؟ لماذا نحتاج إلى "دليل بصري"؟

griesemer ماذا لو تم تبني فكرة velovix ولكن مع builtin تحتوي على وظيفة محددة مسبقًا تحول الخطأ إلى الذعر وقمنا بإزالة مطلب أن دالة over-arching لها قيمة إرجاع خطأ؟

الفكرة هي ، إذا كانت الوظيفة الشاملة لا تُرجع الخطأ ، فإن استخدام try بدون معالج الأخطاء يعد خطأ في وقت الترجمة.

يمكن أيضًا استخدام معالج الأخطاء للالتفاف على الخطأ الذي سيتم إرجاعه قريبًا باستخدام مكتبات متنوعة وما إلى ذلك في موقع الخطأ ، بدلاً من defer في الجزء العلوي الذي يعدل خطأ تم إرجاعه مسمى.

تضمين التغريدة

لماذا يجب أن يكون معالج الأخطاء مطلوبًا؟ لا يمكن أن يكون لا شيء افتراضيا؟ لماذا نحتاج إلى "دليل بصري"؟

هذا هو لمعالجة المخاوف التي

1. اقتراح try كما هو الآن قد يثني الناس عن تقديم سياق لأخطائهم لأن القيام بذلك ليس واضحًا تمامًا.

إن وجود معالج في المقام الأول يجعل توفير السياق أسهل ، ووجود المعالج وسيطة مطلوبة يرسل رسالة: الحالة الشائعة والموصى بها هي معالجة الخطأ أو تحديد سياقه بطريقة ما ، وليس مجرد تمريره إلى المكدس. إنه يتماشى مع التوصية العامة من مجتمع Go.

1. قلق من وثيقة الاقتراح الأصلي. نقلته في تعليقي الأول:

ولم يكن واضحًا أيضًا ما إذا كان السماح بمعالج أخطاء اختياري سيؤدي إلى تجاهل المبرمجين لمعالجة الأخطاء بشكل كامل. سيكون من السهل أيضًا إجراء معالجة مناسبة للأخطاء في كل مكان ولكن تفوت أي محاولة. وهكذا دواليك.

الاضطرار إلى تمرير nil صريح يجعل من الصعب نسيان التعامل مع الخطأ بشكل صحيح. عليك أن تقرر صراحة عدم معالجة الخطأ بدلاً من القيام بذلك ضمنيًا عن طريق ترك حجة.

مزيد من التفكير في العودة المشروطة المذكورة بإيجاز على https://github.com/golang/go/issues/32437#issuecomment -498947603.
يبدو
return if f, err := os.Open("/my/file/path"); err != nil
سيكون أكثر توافقًا مع كيفية ظهور Go في if .

إذا أضفنا قاعدة لبيان return if فإن ذلك
عندما لا يكون تعبير الشرط الأخير (مثل err != nil ) موجودًا ،والمتغير الأخير للإعلان في عبارة return if هو من النوع error ،ثم ستتم مقارنة قيمة المتغير الأخير تلقائيًا بـ nil كشرط ضمني.

ثم يمكن اختصار العبارة return if إلى:
return if f, err := os.Open("my/file/path")

وهو قريب جدًا من نسبة التشويش التي يوفرها try .
إذا قمنا بتغيير return if إلى try ، فسيصبح
try f, err := os.Open("my/file/path")
يصبح مرة أخرى مشابهًا للصيغ الأخرى المقترحة لـ try في هذا الموضوع ، على الأقل من الناحية التركيبية.
شخصيا ، ما زلت أفضل return if على try في هذه الحالة لأنه يجعل نقاط الخروج من الوظيفة واضحة للغاية. على سبيل المثال ، عند تصحيح الأخطاء ، غالبًا ما أبرز الكلمة الأساسية return داخل المحرر لتحديد جميع نقاط الخروج لوظيفة كبيرة.

لسوء الحظ ، لا يبدو أنه يساعد بشكل كافٍ في إزعاج إدراج تسجيل تصحيح الأخطاء أيضًا.
ما لم نسمح أيضًا بكتلة body مقابل return if ، مثل
إبداعي:

        return if f, err := os.Open("my/path") 

عند التصحيح:

-       return if f, err := os.Open("my/path") 
+       return if f, err := os.Open("my/path") {
+               fmt.Printf("DEBUG: os.Open: %s\n", err)
+       }

أفترض أن معنى كتلة الجسم البالغة return if واضح. سيتم تنفيذه قبل defer والعودة.

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

velovix لقد أحببنا تمامًا فكرة try مع وظيفة معالج صريحة كوسيطة ثانية. ولكن كان هناك الكثير من الأسئلة التي لم يكن لها إجابات واضحة ، كما ينص مستند التصميم. لقد أجبت على بعضها بطريقة تبدو معقولة لك. من المحتمل جدًا (وكانت تلك تجربتنا داخل فريق Go Team) ، أن يعتقد شخص آخر أن الإجابة الصحيحة مختلفة تمامًا. على سبيل المثال ، أنت تعلن أنه يجب تقديم وسيطة المعالج دائمًا ، ولكن يمكن أن تكون nil ، لتوضيح ذلك ، فنحن لا نهتم بمعالجة الخطأ. الآن ماذا يحدث إذا قدم المرء قيمة دالة (ليست قيمة حرفية nil ) ، وقيمة هذه الوظيفة (مخزنة في متغير) تصادف أنها لا شيء؟ قياسا على القيمة الصريحة nil ، لا يلزم أي معالجة. لكن قد يجادل آخرون بأن هذا خطأ في الكود. أو ، بدلاً من ذلك ، يمكن للمرء أن يسمح بحجج معالِج لا قيمة له ، ولكن بعد ذلك قد تعالج الوظيفة أخطاء معالجة غير متسقة في بعض الحالات وليس في حالات أخرى ، وليس من الواضح بالضرورة من الكود الذي يفعله المرء ، لأنه يبدو كما لو كان المعالج موجودًا دائمًا . حجة أخرى هي أنه من الأفضل أن يكون لديك إعلان عالي المستوى لمعالج الأخطاء لأن ذلك يوضح تمامًا أن الوظيفة تتعامل مع الأخطاء. ومن هنا جاء defer . ربما هناك المزيد.

سيكون من الجيد معرفة المزيد عن هذا القلق. إن أسلوب الترميز الحالي الذي يستخدم عبارات if لاختبار الأخطاء واضح بقدر الإمكان. من السهل جدًا إضافة معلومات إضافية إلى الخطأ ، على أساس فردي (لكل حالة). غالبًا ما يكون من المنطقي معالجة جميع الأخطاء المكتشفة في وظيفة بطريقة موحدة ، والتي يمكن إجراؤها من خلال التأجيل - وهذا ممكن بالفعل الآن. إن حقيقة أننا نمتلك بالفعل جميع الأدوات للتعامل مع الأخطاء بشكل جيد في اللغة ، ومشكلة بنية المعالج التي لا تكون متعامدة للتأجيل ، هي التي دفعتنا إلى ترك آلية جديدة فقط لزيادة الأخطاء.

griesemer - IIUC ، أنت تقول أنه بالنسبة لسياقات الخطأ المعتمدة على موقع الاستدعاء ، فإن عبارة if الحالية جيدة. حيث إن هذه الوظيفة الجديدة try مفيدة للحالات التي يكون فيها التعامل مع أخطاء متعددة في مكان واحد مفيدًا.

أعتقد أن القلق كان أنه في حين أن القيام ببساطة بـ if err != nil { return err} قد يكون جيدًا في بعض الحالات ، فإنه يوصى عادةً بتزيين الخطأ قبل العودة. ويبدو أن هذا الاقتراح يعالج الاقتراح السابق ولا يفعل الكثير للأخير. مما يعني أنه سيتم تشجيع الأشخاص على استخدام نمط الإرجاع السهل.

agnivade أنت محق ، هذا الاقتراح لا يفعل شيئًا بالضبط للمساعدة في زخرفة الخطأ (لكن للتوصية باستخدام defer ). أحد الأسباب هو أن آليات اللغة لهذا موجودة بالفعل. بمجرد طلب زخرفة الخطأ ، خاصةً على أساس الخطأ الفردي ، فإن المقدار الإضافي من النص المصدر لرمز الزخرفة يجعل if أقل صعوبة بالمقارنة. إنها الحالات التي لا يلزم فيها الزخرفة ، أو حيث تكون الزخرفة دائمًا كما هي ، حيث تصبح اللوحة المعيارية مصدر إزعاج مرئي ثم تنتقص من الرمز المهم.

يتم تشجيع الناس بالفعل على استخدام نمط الإرجاع السهل ، try أو بدون try ، هناك القليل للكتابة. تعال إلى التفكير في الأمر ، الطريقة الوحيدة لتشجيع زخرفة الأخطاء هي جعلها إلزامية ، لأنه بغض النظر عن الدعم اللغوي المتاح ، فإن أخطاء التزيين ستتطلب المزيد من العمل.

تتمثل إحدى طرق تحسين الصفقة في السماح فقط بشيء مثل try (أو أي تدوين اختصار مماثل) _ if_ يتم توفير معالج صريح (ربما فارغ) في مكان ما (لاحظ أن تصميم المسودة الأصلي لم يكن به مثل هذا شرط إما).

لست متأكدًا من أننا نريد الذهاب بعيدًا. اسمحوا لي أن أعيد التأكيد على أن الكثير من الشفرات الدقيقة تمامًا ، على سبيل المثال الأجزاء الداخلية للمكتبة ، لا تحتاج إلى تزيين الأخطاء في كل مكان. من الجيد نشر الأخطاء وتزيينها قبل مغادرتها لنقاط دخول واجهة برمجة التطبيقات ، على سبيل المثال. (في الواقع ، فإن تزيينها في كل مكان لن يؤدي إلا إلى أخطاء زخرفية زائدة ، والتي ، مع إخفاء الجناة الحقيقيين ، تجعل من الصعب تحديد الأخطاء المهمة ؛ مثل الكثير من التسجيل المطول المفرط يمكن أن يجعل من الصعب رؤية ما يحدث بالفعل).

أعتقد أنه يمكننا أيضًا إضافة وظيفة catch ، والتي ستكون زوجًا رائعًا ، لذلك:

func a() int {
  x := randInt()
  // let's assume that this is what recruiters should "fix" for us
  // or this happens in 3rd-party package.
  if x % 1337 != 0 {
    panic("not l33t enough")
  }
  return x
}

func b() error {
  // if a() panics, then x = 0, err = error{"not l33t enough"}
  x, err := catch(a())
  if err != nil {
    return err
  }
  sendSomewhereElse(x)
  return nil
}

// which could be simplified even further

func c() error {
  x := try(catch(a()))
  sendSomewhereElse(x)
  return nil
}

في هذا المثال ، قد يؤدي catch() recover() إلى حالة من الذعر و return ..., panicValue .
بالطبع ، لدينا حالة ركنية واضحة حيث لدينا func ، والتي تُرجع أيضًا خطأ. في هذه الحالة ، أعتقد أنه سيكون من المناسب مجرد تمرير قيمة الخطأ.

لذلك ، في الأساس ، يمكنك بعد ذلك استخدام catch () لاستعادة () الذعر بالفعل وتحويلها إلى أخطاء.
هذا يبدو مضحكًا جدًا بالنسبة لي ، لأن Go ليس لديه استثناءات في الواقع ، ولكن في هذه الحالة لدينا نمط محاولة () - catch () أنيق جدًا ، وهذا أيضًا لا ينبغي أن يفجر قاعدة التعليمات البرمجية بالكامل بشيء مثل Java ( catch(Throwable) في الرئيسي + throws LiterallyAnything ). يمكنك بسهولة معالجة ذعر شخص ما مثل تلك الأخطاء المعتادة. لدي حاليًا حوالي 6 مليون + LoC in Go في مشروعي الحالي ، وأعتقد أن هذا من شأنه أن يبسط الأمور على الأقل بالنسبة لي.

griesemer شكرًا على تلخيص المناقشة.

ألاحظ أن هناك نقطة واحدة مفقودة: جادل بعض الأشخاص بأنه يجب علينا الانتظار مع هذه الميزة حتى نحصل على الأدوية الجنيسة ، والتي نأمل أن تسمح لنا بحل هذه المشكلة بطريقة أكثر أناقة.

علاوة على ذلك ، أحب اقتراح velovix ، وبينما أقدر أن هذا يثير بعض الأسئلة كما هو موضح في المواصفات ، أعتقد أنه يمكن الإجابة عليها بسهولة بطريقة معقولة ، كما فعلvelovix بالفعل.

علي سبيل المثال:

• ماذا يحدث إذا قدم المرء قيمة دالة (وليس قيمة حرفية صفرية) ، وكانت قيمة هذه الوظيفة (مخزنة في متغير) صفرًا؟ => لا تتعامل مع الخطأ ، الفترة. يكون هذا مفيدًا في حالة اعتماد معالجة الأخطاء على السياق وتم تعيين متغير المعالج اعتمادًا على ما إذا كانت معالجة الخطأ مطلوبة أم لا. إنه ليس خطأ ، بل هو ميزة. :)

• حجة أخرى هي أنه من الأفضل أن يكون لديك إعلان عالي المستوى لمعالج الأخطاء لأن ذلك يوضح تمامًا أن الوظيفة تتعامل مع الأخطاء. => لذا حدد معالج الخطأ في الجزء العلوي من الوظيفة كدالة إغلاق مسماة واستخدمها ، لذلك من الواضح أيضًا أنه يجب معالجة الخطأ. هذه ليست مشكلة خطيرة ، بل هي أكثر من متطلبات الأسلوب.

ما هي المخاوف الأخرى التي كانت هناك؟ أنا متأكد من أنه يمكن الرد عليهم جميعًا بطريقة مماثلة بطريقة معقولة.

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

تضمين التغريدة

الآن ماذا يحدث إذا قدم المرء قيمة دالة (وليس قيمة حرفية صفرية) ، وقيمة هذه الوظيفة (مخزنة في متغير) تصادف أنها لا شيء؟ عن طريق القياس مع القيمة الصريحة للصفر ، لا يلزم أي معالجة. لكن قد يجادل آخرون بأن هذا خطأ في الكود.

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

حجة أخرى هي أنه من الأفضل أن يكون لديك إعلان عالي المستوى لمعالج الأخطاء لأن ذلك يوضح تمامًا أن الوظيفة تتعامل مع الأخطاء. ومن هنا جاء defer .

كما ذكر beoran ، فإن تعريف المعالج على أنه إغلاق بالقرب من الجزء العلوي من الوظيفة سيبدو مشابهًا جدًا في الأسلوب ، وهذا ما أتوقعه شخصيًا أن يستخدم الأشخاص المعالجات بشكل شائع. على الرغم من أنني أقدر الوضوح الذي اكتسبته حقيقة أن جميع الوظائف التي تتعامل مع الأخطاء ستستخدم defer ، فقد يصبح أقل وضوحًا عندما تحتاج الوظيفة إلى التمحور في إستراتيجية معالجة الأخطاء الخاصة بها في منتصف الطريق أسفل الوظيفة. بعد ذلك ، سيكون هناك defer s للنظر إليهما وسيتعين على القارئ التفكير في كيفية تفاعلهما مع بعضهما البعض. هذا موقف أعتقد فيه أن حجة المعالج ستكون أكثر وضوحًا وراحة ، وأعتقد أن هذا سيكون سيناريو شائعًا نسبيًا.

هل من الممكن جعله يعمل بدون أقواس؟

أي شيء مثل:
a := try func(some)

Cyberax - كما ذكرنا سابقًا ، من الضروري جدًا قراءة مستند التصميم بعناية قبل النشر. نظرًا لأن هذه مشكلة ذات حركة مرور عالية ، فقد اشترك فيها الكثير من الأشخاص.

يناقش المستند العوامل مقابل الوظائف بالتفصيل.

أنا أحب هذا أكثر بكثير مما أحببت إصدار أغسطس.

أعتقد أن الكثير من التعليقات السلبية ، التي لا تتعارض تمامًا مع عمليات الإرجاع بدون الكلمة الرئيسية return ، يمكن تلخيصها في نقطتين:

1. لا يحب الأشخاص معلمات النتائج المسماة ، والتي ستكون مطلوبة في معظم الحالات
2. لا يشجع على إضافة سياق مفصل للأخطاء

انظر على سبيل المثال:

• https://github.com/golang/go/issues/32437#issuecomment -498937169
• https://github.com/golang/go/issues/32437#issuecomment -498967099
• https://github.com/golang/go/issues/32437#issuecomment -499194787
• https://github.com/golang/go/issues/32437#issuecomment -499309304

نقض هذين الاعتراضين على التوالي:

1. "قررنا أن [معلمات النتائج المسماة] كانت جيدة"
2. "لن يجعلك أحد تستخدم try " / لن يكون مناسبًا لـ 100٪ من الحالات

ليس لدي حقًا ما أقوله عن 1 (لا أشعر بقوة تجاه ذلك). ولكن فيما يتعلق بـ 2 ، فقد لاحظت أن الاقتراح المهيب لم يكن به هذه المشكلة ، كما أن معظم المقترحات المضادة لا تحتوي أيضًا على هذه المشكلة.

على وجه الخصوص ، لم يواجه الاقتراح المضاد tryf (الذي تم نشره بشكل مستقل مرتين في سلسلة الرسائل هذه) ولا الاقتراح المضاد try(X, handlefn) (الذي كان جزءًا من تكرارات التصميم) هذه المشكلة.

أعتقد أنه من الصعب المجادلة بأن try ، كما هو ، سوف يدفع الناس بعيدًا عن تزيين الأخطاء بسياق ذي صلة ونحو زخرفة خطأ عامة واحدة لكل وظيفة.

لهذه الأسباب أعتقد أن الأمر يستحق محاولة معالجة هذه المشكلة وأريد اقتراح حل ممكن:

1. حاليًا لا يمكن أن تكون المعلمة defer سوى استدعاء دالة أو طريقة. اسمح لـ defer أن يكون لديك أيضًا اسم دالة أو دالة حرفية ، على سبيل المثال

defer func(...) {...}
defer packageName.functionName

1. عندما يواجه الذعر أو التأجيل هذا النوع من التأجيل ، فسوف يستدعيون الوظيفة لتمرير القيمة الصفرية لجميع معلماتهم

2. السماح لـ try بالحصول على أكثر من معلمة واحدة

3. عندما يصادف try النوع الجديد من التأجيل ، فإنه سوف يستدعي الوظيفة التي تمرر مؤشرًا إلى قيمة الخطأ كمعامل أول متبوعًا بجميع المعلمات الخاصة بـ try ، باستثناء المعلمة الأولى.

على سبيل المثال ، معطى:

func errorfn() error {
    return errors.New("an error")
}


func f(fail bool) {
    defer func(err *error, a, b, c int) {
        fmt.Printf("a=%d b=%d c=%d\n", a, b, c)
    }
    if fail {
        try(errorfn, 1, 2, 3)
    }
}

سيحدث ما يلي:

f(false)        // prints "a=0 b=0 c=0"
f(true)         // prints "a=1 b=2 c=3"

يمكن إعادة كتابة الكود الموجود في https://github.com/golang/go/issues/32437#issuecomment -499309304 بواسطة zeebo على النحو التالي:

func (c *Config) Build() error {
    defer func(err *error, msg string, args ...interface{}) {
        if *err == nil || msg == "" {
            return
        }
        *err = errors.WithMessagef(err, msg, args...)
    }
    pkgPath := try(c.load(), "load config dir")

    b := bytes.NewBuffer(nil)
    try(templates.ExecuteTemplate(b, "main", c), "execute main template")

    buf := try(format.Source(b.Bytes()), "format main template")

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)
    // ...
}

وتعريف ErrorHandlef على أنه:

func HandleErrorf(err *error, format string, args ...interface{}) {
        if *err != nil && format != "" {
                *err = fmt.Errorf(format + ": %v", append(args, *err)...)
        }
}

كل شخص يسعى للحصول عليه بعد tryf مجانًا ، بدون سحب سلاسل تنسيق نمط fmt إلى اللغة الأساسية.

هذه الميزة متوافقة مع الإصدارات السابقة لأن defer لا يسمح بتعبيرات الوظيفة كوسيطة لها. لا يقدم كلمات رئيسية جديدة.
التغييرات التي يجب إجراؤها لتنفيذه ، بالإضافة إلى تلك الموضحة في https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md ، هي:

1. تعليم المحلل اللغوي حول النوع الجديد من التأجيل
2. قم بتغيير مدقق النوع للتحقق من أن جميع المؤجِّلات التي لها وظيفة كمعامل (بدلاً من استدعاء) داخل دالة لها نفس التوقيع أيضًا
3. قم بتغيير مدقق النوع للتحقق من أن المعلمات التي تم تمريرها إلى try تطابق توقيع الوظائف التي تم تمريرها إلى defer
4. تغيير الخلفية (؟) لإنشاء استدعاء deferproc المناسب
5. قم بتغيير تنفيذ try لنسخ وسيطاته إلى وسيطات المكالمة المؤجلة عندما يواجه استدعاء مؤجل بواسطة النوع الجديد من المؤجل.

بعد تعقيدات مسودة التصميم check/handle ، فوجئت بسرور لرؤية هذه الأرض المقترحة الأكثر بساطة وواقعية على الرغم من أنني أشعر بخيبة أمل لأنه كان هناك الكثير من التراجع ضدها.

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

فيما يتعلق ببعض النقاط المحددة:

1. الشيء الوحيد الذي لا يعجبني في الاقتراح هو الحاجة إلى وجود معلمة إرجاع خطأ مسمى عند استخدام defer ولكن بعد أن قلت ذلك ، لا يمكنني التفكير في أي حل آخر لا يتعارض معه الطريقة التي تعمل بها بقية اللغة. لذلك أعتقد أنه سيتعين علينا فقط قبول هذا إذا تم اعتماد الاقتراح.

2. من المؤسف أن try لا يعمل بشكل جيد مع حزمة الاختبار للوظائف التي لا تُرجع قيمة الخطأ. سيكون الحل المفضل لدي لهذا هو الحصول على وظيفة مضمنة ثانية (ربما ptry أو must ) والتي دائمًا ما تصيب بالذعر بدلاً من إرجاعها عند مواجهة خطأ غير معدوم وبالتالي يمكن أن تكون كذلك تستخدم مع الوظائف المذكورة أعلاه (بما في ذلك main ). على الرغم من رفض هذه الفكرة في التكرار الحالي للاقتراح ، فقد شكلت انطباعًا بأنها كانت "دعوة قريبة" وبالتالي قد تكون مؤهلة لإعادة النظر فيها.

3. أعتقد أنه سيكون من الصعب على الناس فهم ما يفعله go try(f) أو defer try(f) ولذلك من الأفضل منعهم تمامًا.

4. أتفق مع أولئك الذين يعتقدون أن تقنيات معالجة الأخطاء الحالية ستبدو أقل طولًا إذا لم يقم go fmt بإعادة كتابة سطر واحد if كشوفات الحساب. أنا شخصياً أفضل قاعدة بسيطة وهي أن هذا سيسمح به لأي _ بيان واحد if سواء كان الأمر يتعلق بمعالجة الأخطاء أم لا. في الواقع ، لم أتمكن أبدًا من فهم سبب عدم السماح بذلك حاليًا عند كتابة وظائف أحادية السطر حيث يتم وضع الجسم على نفس السطر الذي يُسمح فيه بالإعلان.

في حالة أخطاء التزيين

func myfunc()( err error){
try(thing())
defer func(){
err = errors.Wrap(err,"more context")
}()
}

هذا يبدو أكثر استطالة وألمًا من النماذج الحالية ، وليس موجزًا ​​مثل الفحص / المقبض. يعتبر متغير try غير المغلف () أكثر إيجازًا ، لكن يبدو أن الأشخاص سينتهي بهم الأمر باستخدام مزيج من المحاولة وإرجاع الخطأ العادي. لست متأكدًا من أنني أحب فكرة المزج بين المحاولة وإرجاع الخطأ البسيط ، لكنني بيعت تمامًا لأخطاء التزيين (وأتطلع إلى Is / As). اجعلني أعتقد أنه في حين أن هذا أنيق من الناحية التركيبية ، فأنا لست متأكدًا من أنني أرغب في استخدامه بالفعل. شعرت بفحص / مقبض بشيء أود أن أحتضنه بشكل أكثر شمولاً.

أنا حقًا أحب بساطة هذا ونهج "افعل شيئًا واحدًا جيدًا". في مترجم GoAWK الخاص بي سيكون مفيدًا للغاية - لدي حوالي 100 if err != nil { return nil } تركيبات يمكن تبسيطها وترتيبها ، وهذا في قاعدة بيانات صغيرة إلى حد ما.

لقد قرأت تبرير الاقتراح لجعله مدمجًا وليس كلمة رئيسية ، ويتلخص ذلك في عدم الاضطرار إلى ضبط المحلل اللغوي. لكن ليس هذا قدرًا ضئيلًا نسبيًا من الألم للمترجمين وكتاب الأدوات ، في حين أن الحصول على أقواس إضافية و this-look-like-a-function-but-not read the issues سيكون شيئًا كل المبرمجين و الكود- القراء يجب أن يتحملوا. في رأيي ، الحجة (عذر؟ :-) القائلة بأن "ولكن panic() يتحكم في التدفق" لا تقطعها ، لأن الذعر والتعافي بطبيعتهما استثنائيان ، بينما try() سوف أن تكون معالجة الأخطاء الطبيعية والتحكم في التدفق.

سأقدر ذلك بالتأكيد حتى لو استمر هذا كما هو ، ولكن أفضل تفضيلي هو أن يكون تدفق التحكم الطبيعي واضحًا ، على سبيل المثال ، يتم عبر كلمة رئيسية.

أنا أؤيد هذا الاقتراح. إنه يتجنب أكبر حجوزاتي بشأن الاقتراح السابق: عدم التعامد البالغ handle بالنسبة إلى defer .

أود أن أذكر جانبين لا أعتقد أنه تم تسليط الضوء عليهما أعلاه.

أولاً ، على الرغم من أن هذا الاقتراح لا يجعل من السهل إضافة نص خطأ خاص بالسياق إلى خطأ ، فإنه _ يفعل _ يجعل من السهل إضافة معلومات تتبع أخطاء إطار المكدس إلى خطأ: https://play.golang.org/p / YL1MoqR08E6

ثانيًا ، يمكن القول إن try هو حل عادل لمعظم المشاكل الكامنة وراء https://github.com/golang/go/issues/19642. لأخذ مثال من هذه المشكلة ، يمكنك استخدام try لتجنب كتابة جميع قيم الإرجاع في كل مرة. من المحتمل أن يكون هذا مفيدًا أيضًا عند إرجاع أنواع البنى حسب القيمة بأسماء طويلة.

func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
    xx := int(x)
    if f.NumGlyphs() <= xx {
        try(ErrNotFound)
    }
    i := f.cached.locations[xx+0]
    j := f.cached.locations[xx+1]
    if j < i {
        try(errInvalidGlyphDataLength)
    }
    if j-i > maxGlyphDataLength {
        try(errUnsupportedGlyphDataLength)
    }
    buf, err = b.view(&f.src, int(i), int(j-i))
    return buf, i, j - i, err
}

أنا أحب هذا الاقتراح أيضا.

ولدي طلب.

مثل make ، هل يمكننا السماح لـ try بأخذ عدد متغير من المعلمات

• حاول (و):
  على النحو الوارد أعلاه.
  قيمة خطأ الإرجاع إلزامية (كمعامل إرجاع آخر).
  نموذج الاستخدام الأكثر شيوعًا
• حاول (f، doPanic bool):
  على النحو الوارد أعلاه ، ولكن إذا كنت تفعل ذلك ، فهلع (يخطئ) بدلاً من العودة.
  في هذا الوضع ، ليس من الضروري إرجاع قيمة الخطأ.
• حاول (f، fn):
  على النحو الوارد أعلاه ، ولكن اتصل fn (يخطئ) قبل العودة.
  في هذا الوضع ، ليس من الضروري إرجاع قيمة الخطأ.

بهذه الطريقة ، يمكن أن يتعامل مع جميع حالات الاستخدام ، بينما لا يزال صريحًا. مزاياه:

• صريح دائمًا - لا داعي للاستدلال على الذعر أو ضبط الخطأ والعودة
• يدعم معالج خاص بالسياق (لكن بدون سلسلة معالج)
• يدعم حالات الاستخدام التي لا يوجد فيها متغير إرجاع خطأ
• يجب أن يدعم (...) دلالات

في حين أن التكرار if err !=nil { return ... err } هو بالتأكيد تلعثم قبيح ، فأنا مع هؤلاء
الذين يعتقدون أن اقتراح try () منخفض للغاية فيما يتعلق بسهولة القراءة وغير صريح إلى حد ما.
استخدام المرتجعات المسماة مشكلة أيضًا.

إذا كان هذا النوع من الترتيب مطلوبًا ، فلماذا لا يكون السكر النحوي هو try(err) لـ
if err !=nil { return err } :

file, err := os.Open("file.go")
try(err)

بالنسبة

file, err := os.Open("file.go")
if err != nil {
   return err
}

وإذا كان هناك أكثر من قيمة إرجاع واحدة ، فقد يكون try(err) return t1, ... tn, err
حيث t1، ... tn هي القيم الصفرية لقيم الإرجاع الأخرى.

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

أفضل من ذلك ، أعتقد أنه سيكون:

file, try(err) := os.Open("file.go")

او حتى

file, err? := os.Open("file.go")

هذا الأخير متوافق مع الإصدارات السابقة (؟ غير مسموح به حاليًا في المعرفات).

(يرتبط هذا الاقتراح بـ https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring-themes. ولكن تبدو أمثلة السمات المتكررة مختلفة لأن ذلك كان في مرحلة كان لا يزال فيها المقبض الصريح قيد المناقشة بدلاً من ترك هذا إلى تأجيل.)

شكرًا لفريق Go على هذا الاقتراح الدقيق والمثير للاهتمام.

تعليق rogpeppe إذا قام try بإضافة إطار المكدس تلقائيًا ، وليس أنا ، فأنا موافق على عدم تشجيع إضافة السياق.

aarzilli - وفقًا لاقتراحك ، هل شرط التأجيل إلزامي في كل مرة نعطي فيها معلمات إضافية لـ tryf ؟

ماذا يحدث إذا فعلت

try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)

ولا تكتب وظيفة مؤجلة؟

تضمين التغريدة

ماذا يحدث إذا فعلت (...) ولم أكتب وظيفة مؤجلة؟

خطأ مطبعي.

في رأيي ، استخدام try لتجنب كتابة جميع قيم الإرجاع هو في الواقع مجرد ضربة أخرى ضده.

func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
    xx := int(x)
    if f.NumGlyphs() <= xx {
        try(ErrNotFound)
    }
    //...

أتفهم تمامًا الرغبة في تجنب الاضطرار إلى كتابة return nil, 0, 0, ErrNotFound ، لكنني أفضل حل هذه المشكلة بطريقة أخرى.

كلمة try لا تعني "رجوع". وهذه هي الطريقة التي يتم استخدامها بها هنا. أفضل في الواقع تغيير الاقتراح بحيث لا يمكن أن يأخذ $ # try error قيمة $ # $ 5 $ # $ مباشرة ، لأنني لا أريد أبدًا أن يكتب أي شخص رمزًا كهذا ^^. يقرأ خطأ . إذا عرضت هذا الرمز على مبتدئ ، فلن يكون لديهم أدنى فكرة عما كانت تفعله هذه المحاولة.

إذا أردنا طريقة لإرجاع القيم الافتراضية وقيمة الخطأ بسهولة ، فلنحل ذلك بشكل منفصل. ربما آخر مثل بنيت

return default(ErrNotFound)

على الأقل هذا يقرأ مع نوع من المنطق.

لكن دعونا لا نسيء استخدام try لحل مشكلة أخرى.

natefinch إذا تم تسمية try المضمن باسم check كما هو الحال في الاقتراح الأصلي ، فسيكون check(err) الذي يقرأ أفضل بكثير ، imo.

إذا وضعنا ذلك جانبًا ، فأنا لا أعرف ما إذا كان كتابة try(err) يعد إساءة حقًا. إنه يقع خارج التعريف بشكل نظيف. ولكن ، من ناحية أخرى ، هذا يعني أيضًا أن هذا قانوني:

a, b := try(1, f(), err)

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

natefinch إذا كنت تصوره على أنه ذعر يرتفع مستوى واحدًا ثم تقوم بأشياء أخرى ، فإنه يبدو فوضويًا جدًا. ومع ذلك ، أنا أتخيلها بشكل مختلف. الدالات التي ترجع الأخطاء في Go تقوم بإرجاع نتيجة بشكل فعال، للاقتراض بشكل فضفاض من مصطلحات Rust. try هي أداة تقوم بفك ضغط النتيجة وإما إرجاع "نتيجة خطأ" إذا كان error != nil ، أو فك جزء T من النتيجة إذا كان error == nil .

بالطبع ، في Go ليس لدينا في الواقع كائنات ناتجة ، لكنها في الواقع نفس النمط ويبدو أن try يبدو وكأنه تدوين طبيعي لهذا النمط. أعتقد أن أي حل لهذه المشكلة سيتعين عليه تدوين بعض جوانب معالجة الأخطاء ، try أن الأمر يبدو معقولًا بالنسبة لي. أقترح أنا والآخرون توسيع قدرة try قليلاً لتتناسب بشكل أفضل مع أنماط معالجة أخطاء Go الحالية ، لكن المفهوم الأساسي يظل كما هو.

ugorji يبدو المتغير try(f, bool) الذي تقترحه مثل must من # 32219.

ugorji يبدو المتغير try(f, bool) الذي تقترحه مثل must من # 32219.

نعم إنه كذلك. لقد شعرت للتو أنه يمكن التعامل مع جميع الحالات الثلاثة بوظيفة مدمجة فردية ، وتلبية جميع حالات الاستخدام بأناقة.

نظرًا لأن try() سحري بالفعل ، ويدرك القيمة المرجعة للخطأ ، فهل يمكن زيادته لإرجاع مؤشر إلى هذه القيمة عند استدعائه في النموذج الصفري (بدون وسيطة)؟ سيؤدي ذلك إلى التخلص من الحاجة إلى عمليات الإرجاع المسماة ، وأعتقد أنه يساعد في الربط المرئي للمكان المتوقع أن يأتي الخطأ منه في البيانات المؤجلة. علي سبيل المثال:

func foo() error {
  defer fmt.HandleErrorf(try(), "important foo context info")
  try(bar())
  try(baz())
  try(etc())
}

تضمين التغريدة
أعتقد أن منطقية على try(f, bool) ستجعل من الصعب قراءتها ومن السهل تفويتها. يعجبني اقتراحك ولكن بالنسبة لحالة الذعر ، أعتقد أنه يمكن ترك ذلك للمستخدمين لكتابة ذلك داخل المعالج من الرمز النقطي الثالث ، على سبيل المثال try(f(), func(err error) { panic('at the disco'); }) ، وهذا يجعله أكثر وضوحًا للمستخدمين من try(f(), true) المخفي

تضمين التغريدة
أعتقد أن منطقية على try(f, bool) ستجعل من الصعب قراءتها ومن السهل تفويتها. يعجبني اقتراحك ولكن بالنسبة لحالة الذعر ، أعتقد أنه يمكن ترك ذلك للمستخدمين لكتابة ذلك داخل المعالج من الرمز النقطي الثالث ، على سبيل المثال try(f(), func(err error) { panic('at the disco'); }) ، وهذا يجعله أكثر وضوحًا للمستخدمين من try(f(), true) المخفي

لمزيد من التفكير ، أميل إلى الاتفاق مع موقفك ومنطقك ، وما زال يبدو أنيقًا كخط واحد.

@ patrick-nyt لا يزال مؤيدًا آخر لتركيب التخصيص _ لإجراء اختبار صفري ، في https://github.com/golang/go/issues/32437#issuecomment -499533464

يظهر هذا المفهوم في 13 إجابة منفصلة لاقتراح الفحص / التعامل
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -المواضيع

f, ?return := os.Open(...)
f, ?panic  := os.Open(...)

لماذا ا؟ لأنه يقرأ مثل Go 1 ، في حين أن try() و check لا يفعل ذلك.

https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md#draft -design

يبدو أن أحد الاعتراضات على try هو أنه تعبير. افترض بدلاً من ذلك أن هناك بيان postfix ? يعني إرجاع إذا لم يكن لا شيء. إليك نموذج الكود القياسي (بافتراض إضافة الحزمة المؤجلة المقترحة ):

func CopyFile(src, dst string) error {
    var err error // Don't need a named return because err is explicitly named
    defer deferred.Annotate(&err, "copy %s %s", src, dst)

    r, err := os.Open(src)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    w, err := os.Create(dst)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    defer deferred.Cond(&err, func(){ os.Remove(dst) })
    _, err = io.Copy(w, r)

    return err
}

مثال pgStore:

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    err?

    defer deferred.Cond(&err, func(){ tx.Rollback() })

    var res int64 
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    // tricky bit: this would not change the value of err 
    // but the deferred.Cond would still be triggered by err being set before
    deferred.Format(err, "insert table")?

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    deferred.Format(err, "insert table2")?

    return tx.Commit()
}

أحب هذا منjargv :

نظرًا لأن try () سحري بالفعل ، وإدراكًا لقيمة إرجاع الخطأ ، فهل يمكن زيادتها لإرجاع مؤشر إلى تلك القيمة عند استدعائها في النموذج الفارغ (وسيطة صفرية)؟ هذا من شأنه أن يلغي الحاجة إلى أسماء العائدات

ولكن بدلاً من التحميل الزائد على الاسم try بناءً على عدد args ، أعتقد أنه يمكن أن يكون هناك سحر آخر مدمج ، على سبيل المثال reterr أو شيء من هذا القبيل.

لقد أطلعت على بعض الحزم المستخدمة كثيرًا ، أبحث عن كود go الذي "يعاني" من معالجة خاطئة ولكن يجب أن يكون مدروسًا جيدًا قبل كتابته ، في محاولة لمعرفة ما سيفعله "السحر" في المحاولة المقترحة ().
حاليًا ، ما لم أساء فهم الاقتراح ، فإن العديد من هؤلاء (على سبيل المثال ليس معالجة الأخطاء الأساسية الفائقة) لن يكسبوا الكثير ، أو سيضطرون إلى الاستمرار في أسلوب معالجة الخطأ "القديم".
مثال من net / http / request.go:

func (r *Request) write(w io.Writer, usingProxy bool, extraHeaders Header, waitForContinue func() bool) (err error) {
"

trace := httptrace.ContextClientTrace(r.Context())
if trace != nil && trace.WroteRequest != nil {
    defer func() {
        trace.WroteRequest(httptrace.WroteRequestInfo{
            Err: err,
        })
    }()
}

// Find the target host. Prefer the Host: header, but if that
// is not given, use the host from the request URL.
//
// Clean the host, in case it arrives with unexpected stuff in it.
host := cleanHost(r.Host)
if host == "" {
    if r.URL == nil {
        return errMissingHost
    }
    host = cleanHost(r.URL.Host)
}

// According to RFC 6874, an HTTP client, proxy, or other
// intermediary must remove any IPv6 zone identifier attached
// to an outgoing URI.
host = removeZone(host)

ruri := r.URL.RequestURI()
if usingProxy && r.URL.Scheme != "" && r.URL.Opaque == "" {
    ruri = r.URL.Scheme + "://" + host + ruri
} else if r.Method == "CONNECT" && r.URL.Path == "" {
    // CONNECT requests normally give just the host and port, not a full URL.
    ruri = host
    if r.URL.Opaque != "" {
        ruri = r.URL.Opaque
    }
}
if stringContainsCTLByte(ruri) {
    return errors.New("net/http: can't write control character in Request.URL")
}
// TODO: validate r.Method too? At least it's less likely to
// come from an attacker (more likely to be a constant in
// code).

// Wrap the writer in a bufio Writer if it's not already buffered.
// Don't always call NewWriter, as that forces a bytes.Buffer
// and other small bufio Writers to have a minimum 4k buffer
// size.
var bw *bufio.Writer
if _, ok := w.(io.ByteWriter); !ok {
    bw = bufio.NewWriter(w)
    w = bw
}

_, err = fmt.Fprintf(w, "%s %s HTTP/1.1\r\n", valueOrDefault(r.Method, "GET"), ruri)
if err != nil {
    return err
}

// Header lines
_, err = fmt.Fprintf(w, "Host: %s\r\n", host)
if err != nil {
    return err
}
if trace != nil && trace.WroteHeaderField != nil {
    trace.WroteHeaderField("Host", []string{host})
}

// Use the defaultUserAgent unless the Header contains one, which
// may be blank to not send the header.
userAgent := defaultUserAgent
if r.Header.has("User-Agent") {
    userAgent = r.Header.Get("User-Agent")
}
if userAgent != "" {
    _, err = fmt.Fprintf(w, "User-Agent: %s\r\n", userAgent)
    if err != nil {
        return err
    }
    if trace != nil && trace.WroteHeaderField != nil {
        trace.WroteHeaderField("User-Agent", []string{userAgent})
    }
}

// Process Body,ContentLength,Close,Trailer
tw, err := newTransferWriter(r)
if err != nil {
    return err
}
err = tw.writeHeader(w, trace)
if err != nil {
    return err
}

err = r.Header.writeSubset(w, reqWriteExcludeHeader, trace)
if err != nil {
    return err
}

if extraHeaders != nil {
    err = extraHeaders.write(w, trace)
    if err != nil {
        return err
    }
}

_, err = io.WriteString(w, "\r\n")
if err != nil {
    return err
}

if trace != nil && trace.WroteHeaders != nil {
    trace.WroteHeaders()
}

// Flush and wait for 100-continue if expected.
if waitForContinue != nil {
    if bw, ok := w.(*bufio.Writer); ok {
        err = bw.Flush()
        if err != nil {
            return err
        }
    }
    if trace != nil && trace.Wait100Continue != nil {
        trace.Wait100Continue()
    }
    if !waitForContinue() {
        r.closeBody()
        return nil
    }
}

if bw, ok := w.(*bufio.Writer); ok && tw.FlushHeaders {
    if err := bw.Flush(); err != nil {
        return err
    }
}

// Write body and trailer
err = tw.writeBody(w)
if err != nil {
    if tw.bodyReadError == err {
        err = requestBodyReadError{err}
    }
    return err
}

if bw != nil {
    return bw.Flush()
}
return nil

}
"

أو كما هو مستخدم في اختبار شامل مثل pprof / profile / profile_test.go:
"
func checkAggregation (prof * Profile، a * aggTest) خطأ {
// تحقق من حفظ العدد الإجمالي لعينات الصفوف.
الإجمالي: = int64 (0)

samples := make(map[string]bool)
for _, sample := range prof.Sample {
    tb := locationHash(sample)
    samples[tb] = true
    total += sample.Value[0]
}

if total != totalSamples {
    return fmt.Errorf("sample total %d, want %d", total, totalSamples)
}

// Check the number of unique sample locations
if a.rows != len(samples) {
    return fmt.Errorf("number of samples %d, want %d", len(samples), a.rows)
}

// Check that all mappings have the right detail flags.
for _, m := range prof.Mapping {
    if m.HasFunctions != a.function {
        return fmt.Errorf("unexpected mapping.HasFunctions %v, want %v", m.HasFunctions, a.function)
    }
    if m.HasFilenames != a.fileline {
        return fmt.Errorf("unexpected mapping.HasFilenames %v, want %v", m.HasFilenames, a.fileline)
    }
    if m.HasLineNumbers != a.fileline {
        return fmt.Errorf("unexpected mapping.HasLineNumbers %v, want %v", m.HasLineNumbers, a.fileline)
    }
    if m.HasInlineFrames != a.inlineFrame {
        return fmt.Errorf("unexpected mapping.HasInlineFrames %v, want %v", m.HasInlineFrames, a.inlineFrame)
    }
}

// Check that aggregation has removed finer resolution data.
for _, l := range prof.Location {
    if !a.inlineFrame && len(l.Line) > 1 {
        return fmt.Errorf("found %d lines on location %d, want 1", len(l.Line), l.ID)
    }

    for _, ln := range l.Line {
        if !a.fileline && (ln.Function.Filename != "" || ln.Line != 0) {
            return fmt.Errorf("found line %s:%d on location %d, want :0",
                ln.Function.Filename, ln.Line, l.ID)
        }
        if !a.function && (ln.Function.Name != "") {
            return fmt.Errorf(`found file %s location %d, want ""`,
                ln.Function.Name, l.ID)
        }
    }
}

return nil

}
"
هذان مثالان يمكنني التفكير فيهما حيث يمكن للمرء أن يقول: "أرغب في خيار أفضل لمعالجة الأخطاء"

هل يمكن لأي شخص أن يوضح كيف يمكن أن تتحسن هذه باستخدام try ()؟

أنا أؤيد هذا الاقتراح في الغالب.

اهتمامي الرئيسي ، الذي تمت مشاركته مع العديد من المعلقين ، هو حول معلمات النتائج المسماة. يشجع الاقتراح الحالي بالتأكيد المزيد من استخدام معلمات النتائج المسماة وأعتقد أن هذا سيكون خطأ. لا أعتقد أن هذه مجرد مسألة أسلوب كما ينص الاقتراح: النتائج المسماة هي ميزة خفية للغة والتي ، في كثير من الحالات ، تجعل الكود أكثر عرضة للخطأ أو أقل وضوحًا. بعد حوالي 8 سنوات من قراءة وكتابة كود Go ، لا أستخدم سوى معلمات النتائج المسماة لغرضين:

• توثيق معلمات النتيجة
• معالجة قيمة نتيجة (عادةً error ) داخل مؤجل

لمهاجمة هذه المشكلة من اتجاه جديد ، إليك فكرة لا أعتقد أنها تتوافق عن كثب مع أي شيء تمت مناقشته في مستند التصميم أو سلسلة تعليقات المشكلة هذه. دعنا نسميها "مؤجلون الخطأ":

السماح باستخدام التأجيل لاستدعاء الوظائف بمعامل خطأ ضمني.

لذلك إذا كان لديك وظيفة

func f(err error, t1 T1, t2 T2, ..., tn Tn) error

بعد ذلك ، في دالة g حيث نوع معلمة النتيجة الأخيرة error (على سبيل المثال ، أي دالة يتم فيها استخدام try ) ، استدعاء لـ f يمكن تأجيلها على النحو التالي:

func g() (R0, R0, ..., error) {
    defer f(t0, t1, ..., tn) // err is implicit
}

دلالات إرجاء الخطأ هي:

1. تم استدعاء الاستدعاء المؤجل لـ f بمعامل النتيجة الأخير g كمعامل إدخال أول f
2. يتم استدعاء f فقط إذا لم يكن هذا الخطأ صفريًا
3. تم تعيين نتيجة f لمعامل النتيجة الأخير g

لذا لاستخدام مثال من مستند تصميم معالجة الأخطاء القديم ، باستخدام ميزة إرجاء الخطأ والمحاولة ، يمكننا القيام بذلك

func printSum(a, b string) error {
    defer func(err error) error {
        return fmt.Errorf("printSum(%q + %q): %v", a, b, err)
    }()
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x+y)
    return nil
}

إليك كيفية عمل HandleErrorf:

func printSum(a, b string) error {
    defer handleErrorf("printSum(%q + %q)", a, b)
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x+y)
    return nil
}

func handleErrorf(err error, format string, args ...interface{}) error {
    return fmt.Errorf(format+": %v", append(args, err)...)
}

إحدى الحالات التي يجب حلها هي كيفية التعامل مع الحالات التي يكون من الغامض فيها أي شكل من أشكال التأجيل نستخدمه. أعتقد أن هذا يحدث فقط مع الوظائف (غير العادية جدًا) ذات التوقيعات مثل هذا:

func(error, ...error) error

يبدو من المعقول أن نقول إن هذه الحالة يتم التعامل معها بطريقة غير مؤجلة للخطأ (وهذا يحافظ على التوافق مع الإصدارات السابقة).

بالتفكير في هذه الفكرة في اليومين الماضيين ، فهي سحرية بعض الشيء ، لكن تجنب معلمات النتائج المسماة ميزة كبيرة لصالحها. نظرًا لأن try يشجع على المزيد من استخدام defer للتلاعب بالأخطاء ، فمن المنطقي أن defer يمكن تمديده ليناسب هذا الغرض بشكل أفضل. أيضًا ، هناك تماثل معين بين try و مؤجل الخطأ.

أخيرًا ، تعد أدوات تأجيل الأخطاء مفيدة اليوم حتى بدون محاولة ، لأنها تحل محل استخدام معلمات النتائج المسماة لمعالجة عوائد الخطأ. على سبيل المثال ، إليك نسخة معدلة من بعض التعليمات البرمجية الحقيقية:

// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) (_ []*File, err error) {
    files := make([]*file, len(keys))

    defer func() {
        if err != nil {
            // Return any successfully retrieved files.
            for _, f := range files {
                if f != nil {
                    c.put(f)
                }
            }
        }
    }()

    // ...
}

مع ميزة "تأجيل الخطأ" ، يصبح هذا:

// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) ([]*File, error) {
    files := make([]*file, len(keys))

    defer func(err error) error {
        // Return any successfully retrieved files.
        for _, f := range files {
            if f != nil {
                c.put(f)
            }
        }
        return err
    }()

    // ...
}

beoran فيما يتعلق بتعليقك أننا يجب أن ننتظر الأدوية. لن تساعد العوامل العامة هنا - يرجى قراءة الأسئلة الشائعة .

فيما يتعلق باقتراحاتك بشأن السلوك الافتراضي لـ velovix try الوسيطتين: كما قلت سابقًا ، فإن فكرتك عن الخيار المعقول الواضح هي كابوس شخص آخر.

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

(أحب أن يكون لدي معالج ، لهذا الأمر. إنه أحد مقترحاتنا السابقة. وإذا اعتمدنا try كما هو ، فلا يزال بإمكاننا التحرك نحو try مع معالج في الأمام -طريقة متوافقة - على الأقل إذا كان المعالج اختياريًا. ولكن دعنا نتخذ خطوة واحدة في كل مرة.)

aarzilli شكرا على اقتراحك .

طالما أن أخطاء التزيين اختيارية ، فسيميل الناس إلى عدم القيام بذلك (إنه عمل إضافي بعد كل شيء). انظر أيضا تعليقي هنا .

لذلك ، لا أعتقد أن الأشخاص المقترحين try _discourages_ الناس من أخطاء التزيين (إنهم محبطون بالفعل حتى مع if للسبب أعلاه) ؛ هذا أن try لا يشجع على ذلك.

(إحدى طرق تشجيعه هي ربطه بـ try : لا يمكن للمرء استخدام try إلا إذا قام أيضًا بتزيين الخطأ ، أو رفضه صراحة.)

لكن عد إلى اقتراحاتك: أعتقد أنك تقدم الكثير من الآلات هنا. تغيير دلالات defer فقط لجعله يعمل بشكل أفضل لـ try ليس شيئًا نود التفكير فيه ما لم تكن هذه التغييرات defer مفيدة بطريقة أكثر عمومية. أيضًا ، يربط اقتراحك defer مع try وبالتالي يجعل هاتين الآليتين أقل تعامدًا ؛ شيء نريد تجنبه.

ولكن الأهم من ذلك ، أشك في أنك سترغب في إجبار الجميع على كتابة defer فقط حتى يتمكنوا من استخدام try . لكن بدون القيام بذلك ، سنعود إلى المربع الأول: سوف يميل الناس نحو عدم تزيين الأخطاء.

(أحب أن يكون لدي معالج ، لهذا الأمر. إنه أحد مقترحاتنا السابقة. وإذا تبنينا المحاولة كما هي ، فلا يزال بإمكاننا التحرك نحو محاولة مع معالج بطريقة متوافقة مع الأمام - على الأقل إذا كان المعالج اختياري. ولكن دعنا نتخذ خطوة واحدة في كل مرة.)

بالتأكيد ، ربما يكون النهج متعدد الخطوات هو السبيل للذهاب. إذا أضفنا وسيطة معالج اختيارية في المستقبل ، فيمكن إنشاء الأدوات لتحذير الكاتب من try غير المعالج بنفس روح الأداة errcheck . بغض النظر ، أنا أقدر ملاحظاتك!

alanfo شكرا لملاحظاتك الإيجابية.

فيما يتعلق بالنقاط التي ذكرتها:

1) إذا كانت المشكلة الوحيدة مع try هي حقيقة أنه سيتعين على المرء تسمية إرجاع خطأ حتى نتمكن من تزيين خطأ عبر defer ، أعتقد أننا جيدون. إذا تبين أن تسمية النتيجة مشكلة حقيقية ، فيمكننا معالجتها. إحدى الآليات البسيطة التي يمكنني التفكير فيها ستكون متغيرًا مُعلنًا مسبقًا وهو اسم مستعار لنتيجة خطأ (فكر في الأمر على أنه يحمل الخطأ الذي تسبب في أحدث try ). قد تكون هناك أفكار أفضل. لم نقترح هذا لأن هناك آلية بالفعل في اللغة ، وهي تسمية النتيجة.
2) try والاختبار: يمكن معالجة هذا وجعله يعمل. انظر الوثيقة المفصلة.
3) هذا تم تناوله صراحة في الوثيقة التفصيلية.
4) أقر.

benhoyt شكرا لملاحظاتك الإيجابية.

إذا كانت الحجة الرئيسية ضد هذا الاقتراح هي حقيقة أن try مضمّن ، فنحن في مكان رائع. استخدام المدمج هو ببساطة حل عملي لمشكلة التوافق مع الإصدارات السابقة (يحدث أنه لا يتسبب في عمل إضافي للمحلل ، والأدوات وما إلى ذلك - ولكن هذه مجرد فائدة جانبية لطيفة ، وليس السبب الأساسي). هناك أيضًا بعض الفوائد من الاضطرار إلى كتابة أقواس ، وقد تمت مناقشة ذلك بالتفصيل في مستند التصميم (قسم خصائص التصميم المقترح).

كل ما قيل ، إذا كان استخدام أداة عرض مدمجة هي أداة العرض ، فيجب أن نأخذ في الاعتبار الكلمة الأساسية try . لن تكون متوافقة مع الإصدارات السابقة على الرغم من وجود رمز موجود لأن الكلمة الأساسية قد تتعارض مع المعرفات الحالية.

(لكي تكتمل ، هناك أيضًا خيار عامل مثل ? ، والذي سيكون متوافقًا مع الإصدارات السابقة. ومع ذلك ، لا يبدو لي أفضل خيار للغة مثل Go. ولكن مرة أخرى ، إذا كان هذا هو كل ما يتطلبه الأمر لجعل try مستساغًا ، فربما يجب أن نفكر فيه.)

ugorji شكرا لملاحظاتك الإيجابية.

يمكن تمديد try ليأخذ وسيطة إضافية. نفضل أن تأخذ وظيفة فقط بتوقيع func (error) error . إذا كنت تريد الذعر ، فمن السهل توفير وظيفة مساعد من سطر واحد:

func doPanic(err error) error { panic(err) }

من الأفضل الحفاظ على تصميم بسيط try .

@ patrick-nyt ماذا تقترح :

file, err := os.Open("file.go")
try(err)

سيكون ممكنا مع الاقتراح الحالي.

dpinela ، ugorji يُرجى أيضًا قراءة مستند التصميم حول موضوع must مقابل try . من الأفضل أن تبقي try بسيطًا قدر الإمكان. must هو "نمط" شائع في تعبيرات التهيئة ، ولكن ليس هناك حاجة ماسة إلى "إصلاح" ذلك.

jargv شكرا لاقتراحك . هذه فكرة مثيرة للاهتمام (انظر أيضًا تعليقي هنا على هذا الموضوع). كي تختصر:

• try(x) يعمل على النحو المقترح
• يقوم try() بإرجاع *error للإشارة إلى نتيجة الخطأ

ستكون هذه بالفعل طريقة أخرى للوصول إلى النتيجة دون الحاجة إلى تسميتها.

cespare يبدو اقتراح jargv بالنسبة لي أبسط مما تقترحه . إنه يحل نفس مشكلة الوصول إلى الخطأ الناتج. ما رأيك؟

حسب https://github.com/golang/go/issues/32437#issuecomment -499320588:

func doPanic (خطأ خطأ) خطأ {ذعر (يخطئ)}

أتوقع أن تكون هذه الوظيفة شائعة جدًا. هل يمكن تحديد ذلك مسبقًا في "مدمج" (أو في مكان آخر في حزمة قياسية مثل errors )؟

سيء للغاية لدرجة أنك لا تتوقع أن الأدوية الجنيسة قوية بما يكفي لتنفيذها
حاول ، كنت آمل في الواقع أنه سيكون من الممكن القيام بذلك.

نعم ، يمكن أن يكون هذا الاقتراح خطوة أولى ، على الرغم من أنني لا أرى فائدة كبيرة فيه
هو نفسي كما هو عليه الآن.

من المؤكد أن هذه القضية ربما تركز كثيرًا على البدائل التفصيلية ،
لكنه يظهر أن العديد من المشاركين ليسوا سعداء تمامًا
هو - هي. ما يبدو أنه ينقصه هو إجماع واسع حول هذا الاقتراح ...

المرجع vr 7 jun. 2019 01:04 schreef pj [email protected] :

Asper # 32437 (تعليق)
https://github.com/golang/go/issues/32437#issuecomment-499320588 :

func doPanic (خطأ خطأ) خطأ {ذعر (يخطئ)}

أتوقع أن تكون هذه الوظيفة شائعة جدًا. هل يمكن أن يكون هذا محددًا مسبقًا
في "مدمج"؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/golang/go/issues/32437؟email_source=notifications&email_token=AAARM6OOOLLYO5ZCE6VVL2TPZGJWRA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREX99G43VMVBWLNM79
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAARM6K5AOR2DES4QDTNLSTPZGJWRANCNFSM4HTGCZ7Q
.

pjebs ، لقد كتبت الدالة المكافئة عشرات المرات. عادةً ما أسميها "orDie" أو "check". الأمر بسيط للغاية ، ولا توجد حاجة حقيقية لجعله جزءًا من المكتبة القياسية. بالإضافة إلى أشخاص مختلفين قد يرغبون في التسجيل أو أي شيء آخر قبل الإنهاء.

beoran ربما يمكنك توسيع العلاقة بين الأدوية الجنيسة ومعالجة الأخطاء. عندما أفكر فيهم ، يبدو أنهم شيئان مختلفان. علم الوراثة ليس كل ما يمكنه معالجة جميع مشاكل اللغة. إنها القدرة على كتابة وظيفة واحدة يمكن أن تعمل على أنواع متعددة.

يحاول اقتراح معالجة الأخطاء المحدد هذا تقليل الصيغة المعيارية عن طريق تقديم دالة معرّفة مسبقًا try التي تغير التحكم في التدفق في بعض الظروف. علم الوراثة لن يغير تدفق السيطرة. لذلك أنا حقًا لا أرى العلاقة.

كان رد فعلي الأولي على هذا هو 👎 كما تخيلت أن التعامل مع العديد من الاستدعاءات المعرضة للخطأ داخل إحدى الوظائف سيجعل معالجة الخطأ defer مربكًا. بعد قراءة الاقتراح بأكمله ، قلبت رد فعلي على ❤️ و حيث علمت أنه لا يزال من الممكن تحقيق ذلك مع تعقيد منخفض نسبيًا.

carlmjohnson نعم انها بسيطة ولكن ...

لقد كتبت الدالة المكافئة عشرات المرات.

مزايا الوظيفة المُعلنة مسبقًا هي:

1. يمكننا سطر واحد
2. لا نحتاج إلى إعادة التصريح عن الخطأ => وظيفة الذعر في كل حزمة نستخدمها ، أو الحفاظ على موقع مشترك لها. نظرًا لأنه من المحتمل أن يكون الجميع في مجتمع Go ، فإن "الحزمة القياسية" هي الموقع المشترك لها.

griesemer مع متغير معالج الأخطاء لاقتراح المحاولة الأصلي ، لم يعد مطلب الوظيفة الشاملة لإرجاع الخطأ مطلوبًا الآن.

عندما استفسرت عن ذلك لأول مرة عن الخطأ => الذعر ، أشير إلى أن الاقتراح اعتبره أمرًا خطيرًا للغاية (لسبب وجيه). ولكن إذا استخدمنا try() بدون معالج أخطاء في سيناريو لا تقوم فيه الوظيفة الشاملة بإرجاع خطأ ، فإن تحويلها إلى خطأ في وقت الترجمة يخفف من القلق الذي تمت مناقشته في الاقتراح

pjebs لم تكن متطلبات الوظيفة الشاملة لإرجاع خطأ مطلوبة في التصميم الأصلي _if_ تم توفير معالج خطأ. لكنه مجرد تعقيد آخر لـ try . من الأفضل _ كثيرًا_ إبقائها بسيطة. بدلاً من ذلك ، سيكون من الواضح أن يكون لديك وظيفة must منفصلة ، والتي دائمًا ما تنزعج من الخطأ (ولكن بخلاف ذلك مثل try ). ثم يتضح ما يحدث في الكود وليس على المرء أن ينظر إلى السياق.

عامل الجذب الرئيسي لامتلاك مثل هذا must سيكون أنه يمكن استخدامه مع اختبارات الوحدة ؛ خاصة إذا تم تعديل الحزمة testing بشكل مناسب للتعافي من الذعر الناجم عن must والإبلاغ عنها على أنها إخفاقات اختبار بطريقة لطيفة. ولكن لماذا نضيف آلية لغة جديدة أخرى عندما يمكننا فقط ضبط حزمة الاختبار لقبول أيضًا وظيفة الاختبار بالشكل TestXxx(t *testing.T) error ؟ إذا قاموا بإرجاع خطأ ، والذي يبدو طبيعيًا تمامًا بعد كل شيء (ربما كان علينا فعل ذلك من البداية) ، فعندئذٍ try سيعمل بشكل جيد. ستحتاج الاختبارات المحلية إلى مزيد من العمل ، ولكن من المحتمل أن يكون ذلك ممكنًا.

الاستخدام الآخر الشائع نسبيًا لـ must في تعبيرات التهيئة العامة ( must(regexp.Compile... ، إلخ). إذا كان من الجيد أن يكون لديك ، لكن هذا لا يرفعها بالضرورة إلى المستوى المطلوب لميزة لغة جديدة.

griesemer نظرًا لأن must مرتبط بشكل غامض بـ try ، وبالنظر إلى أن الزخم يتجه نحو تنفيذ try ، ألا تعتقد أنه من الجيد التفكير في must في نفس الوقت - حتى لو كان مجرد "ممتع".

الاحتمالات هي أنه إذا لم تتم مناقشتها في هذه الجولة ، فلن يتم تنفيذها / النظر فيها بجدية ، على الأقل لأكثر من 3 سنوات (أو ربما في أي وقت مضى). قد يكون التداخل في المناقشة جيدًا أيضًا بدلاً من البدء من نقطة الصفر ومناقشات إعادة التدوير.

ذكر الكثير من الناس أن must يكمل try بشكل لطيف للغاية.

pjebs بالتأكيد لا يبدو أن هناك أي "زخم نحو تنفيذ try " الآن ... - ولقد نشرنا هذا منذ يومين فقط. ولم يقرر أي شيء. دعونا نعطي هذا بعض الوقت.

لم يفلت منا من أن must يتوافق بشكل رائع مع try ، لكن هذا لا يشبه جعله جزءًا من اللغة. لقد بدأنا فقط في استكشاف هذه المساحة مع مجموعة أكبر من الناس. نحن في الحقيقة لا نعرف حتى الآن ما قد يأتي في دعمها أو ضدها. شكرا.

بعد قضاء ساعات في قراءة جميع التعليقات ووثيقة التصميم التفصيلية ، أردت إضافة وجهات نظري إلى هذا الاقتراح.

سأبذل قصارى جهدي لاحترام طلب ianlancetaylor ليس فقط إعادة ذكر النقاط السابقة ولكن بدلاً من ذلك إضافة تعليقات جديدة إلى المناقشة. ومع ذلك ، لا أعتقد أنه يمكنني تقديم التعليقات الجديدة دون الرجوع إلى حد ما إلى التعليقات السابقة.

اهتمامات

الحمولة الزائدة المؤسفة للتأجيل

إن تفضيل زيادة تحميل الطبيعة الواضحة والمباشرة لـ defer أمر مثير للقلق. إذا كتبت defer closeFile(f) فهذا واضح ومباشر لي ما يحدث ولماذا ؛ في نهاية الوظيفة التي سيتم استدعاؤها. وأثناء استخدام defer مقابل panic() و recover() أقل وضوحًا ، نادرًا ما أستخدمه ولن أراه مطلقًا عند قراءة كود الآخرين.

Spoo لزيادة تحميل defer للتعامل مع الأخطاء أيضًا ليس واضحًا ومربكًا. لماذا الكلمة الرئيسية defer ؟ هل لا يعني defer _ "أفعل لاحقًا" _ بدلاً من _ "ربما في وقت لاحق؟" _

هناك أيضًا القلق الذي ذكره فريق Go بشأن أداء defer . بالنظر إلى ذلك ، يبدو أنه من المؤسف بشكل مضاعف أن يتم النظر في defer لتدفق رمز _ "المسار السريع" _.

لا توجد إحصائيات تثبت حالة استخدام كبيرة

كما ذكر prologic ، هل هذا الاقتراح try() مبني على نسبة كبيرة من الكود الذي سيستخدم حالة الاستخدام هذه ، أم أنه يعتمد بدلاً من ذلك على محاولة تهدئة أولئك الذين اشتكوا من معالجة أخطاء Go؟

أتمنى لو كنت أعرف كيفية إعطائك إحصائيات من قاعدة التعليمات البرمجية الخاصة بي دون مراجعة شاملة لكل ملف وتدوين الملاحظات ؛ لا أعرف كيف استطاعprologic أن يفعل ذلك رغم أنه سعيد.

لكن حسب الروايات المتناقلة ، سأندهش إذا عالجت try() 5٪ من حالات الاستخدام الخاصة بي وأعتقد أنها ستعالج أقل من 1٪. هل تعلم على وجه اليقين أن نتائج الآخرين تختلف اختلافًا كبيرًا؟ هل أخذت مجموعة فرعية من المكتبة القياسية وحاولت معرفة كيفية تطبيقها؟

لأنه بدون إحصائيات معروفة تفيد بأن هذا مناسب لعدد كبير من التعليمات البرمجية في البرية ، يجب أن أسأل هل هذا التغيير الجديد معقدًا للغة والذي سيتطلب من الجميع تعلم المفاهيم الجديدة يعالج حقًا عددًا مقنعًا من حالات الاستخدام؟

يسهل على المطورين تجاهل الأخطاء

هذا تكرار لما لدى الآخرين من تعليقات ، ولكن ما يقدم try() بشكل أساسي هو مماثل من عدة نواحٍ لتبني ببساطة ما يلي كرمز اصطلاحي ، وهذا هو الكود الذي لن يجد طريقه أبدًا إلى أي رمز ذاتي - احترام سفن التطوير:

f, _ := os.Open(filename)

أعلم أنه يمكنني أن أكون أفضل في الكود الخاص بي ، لكنني أعرف أيضًا أن الكثير منا يعتمد على سخاء مطوري Go الآخرين الذين ينشرون بعض الحزم المفيدة للغاية ، ولكن مما رأيته في _ "رمز الأشخاص الآخرين (tm)" _ غالبًا ما يتم تجاهل أفضل الممارسات في معالجة الأخطاء.

على محمل الجد ، هل نريد حقًا تسهيل الأمر على المطورين لتجاهل الأخطاء والسماح لهم بالتعامل مع GitHub بحزم غير قوية؟

يمكن (في الغالب) بالفعل تنفيذ try() في userland

ما لم أسيء فهم الاقتراح - وهو ما أفعله على الأرجح - إليك try() في Go Playground المطبق في userland ، وإن كان ذلك مع قيمة إرجاع واحدة (1) وإرجاع واجهة بدلاً من النوع المتوقع:

package main

import (
    "errors"
    "fmt"
    "strings"
)
func main() {
    defer func() {
        r := recover()
        if r != nil && strings.HasPrefix(r.(string),"TRY:") {
            fmt.Printf("Ouch! %s",strings.TrimPrefix(r.(string),"TRY: "))
        }
    }()
    n := try(badjuju()).(int)
    fmt.Printf("Just chillin %dx!",n)   
}
func badjuju() (int,error) {
    return 10, errors.New("this is a really bad error")
}
func try(args ...interface{}) interface{} {
    err,ok := args[1].(error)
    if ok && err != nil {
        panic(fmt.Sprintf("TRY: %s",err.Error()))
    }
    return args[0]
}

لذلك يمكن للمستخدم إضافة try2() و try3() وهكذا اعتمادًا على عدد قيم الإرجاع التي يحتاجون إلى إرجاعها.

لكن Go سيحتاج فقط إلى ميزة لغة واحدة (1) بسيطة _ لكنها عالمية _ للسماح للمستخدمين الذين يريدون try() بتقديم دعمهم الخاص ، وإن كان لا يزال يتطلب تأكيدًا صريحًا للنوع. أضف _ (متوافقة تمامًا مع الإصدارات السابقة) _ إمكانية Go func لإرجاع عدد متغير من قيم الإرجاع ، على سبيل المثال:

func try(args ...interface{}) ...interface{} {
    err,ok := args[1].(error)
    if ok && err != nil {
        panic(fmt.Sprintf("TRY: %s",err.Error()))
    }
    return args[0:len(args)-2]
}

وإذا تناولت الأدوية الجنيسة أولاً ، فلن تكون تأكيدات النوع ضرورية حتى _ (على الرغم من أنني أعتقد أن حالات استخدام الأدوية الجنيسة يجب أن يتم تقليصها عن طريق إضافة عناصر مدمجة لمعالجة حالات الاستخدام العامة بدلاً من إضافة الدلالات المربكة وسلطة بناء الجملة للأدوية العامة من جافا وآخرون) _

عدم الوضوح

عند دراسة كود الاقتراح أجد أن السلوك غير واضح ومن الصعب نوعًا ما التفكير فيه.

عندما أرى try() يلف تعبيرًا ، ماذا سيحدث إذا تم إرجاع خطأ؟

هل سيتم تجاهل الخطأ فقط؟ أم ستنتقل إلى أول أو أحدث defer ، وإذا كان الأمر كذلك ، فسيقوم تلقائيًا بتعيين متغير باسم err داخل الإغلاق ، أو سيمرره كمعامل _ (I لا ترى معلمة؟) _. وإذا لم يكن اسم خطأ تلقائي ، فكيف يمكنني تسميته؟ وهل يعني ذلك أنه لا يمكنني التصريح عن متغير err الخاص بي في وظيفتي ، لتجنب التعارضات؟

وهل ستسمي كل defer s؟ بترتيب عكسي أم ترتيب عادي؟

أم أنها ستعود من كل من الإغلاق و func حيث تم إرجاع الخطأ؟ _ (شيء لم أكن لأفكر فيه أبدًا إذا لم أقرأ هنا الكلمات التي تشير إلى ذلك.) _

بعد قراءة الاقتراح وجميع التعليقات حتى الآن ما زلت بصراحة لا أعرف إجابات الأسئلة أعلاه. هل هذا هو نوع الميزة التي نريد أن نضيفها إلى لغة يدافع عنها المدافعون عن أنها _ "كابتن واضح؟" _

عدم السيطرة

باستخدام defer ، يبدو أن مطوري التحكم الوحيدين الذين سيتم منحهم هو التفريع إلى _ (الأحدث؟) _ defer . ولكن في تجربتي مع أي طرق تتجاوز func تافه ، عادة ما تكون أكثر تعقيدًا من ذلك.

غالبًا ما وجدت أنه من المفيد مشاركة جانب من معالجة الأخطاء ضمن func - أو حتى عبر package - ولكن بعد ذلك يكون لديك أيضًا معالجة أكثر تحديدًا مشتركة عبر حزمة أخرى أو أكثر.

على سبيل المثال ، يمكنني الاتصال بخمسة (5) func مكالمات تعيد error() من داخل func آخر ؛ دعنا نسميها A() ، B() ، C() ، D() ، و E() . قد أحتاج إلى C() للتعامل مع الأخطاء الخاصة به ، A() ، B() ، D() ، و E() لمشاركة بعض معالجة الأخطاء ، و B() و E() للتعامل بشكل خاص.

لكني لا أعتقد أنه سيكون من الممكن القيام بذلك مع هذا الاقتراح. على الأقل ليس بسهولة.

ومن المفارقات ، مع ذلك ، أن Go لديها بالفعل ميزات لغوية تسمح بمستوى عالٍ من المرونة التي لا تحتاج إلى أن تقتصر على مجموعة صغيرة من حالات الاستخدام ؛ func s والإغلاق. لذا فإن سؤالي الخطابي هو:

_ "لماذا لا نضيف فقط تحسينات طفيفة على اللغة الحالية لمعالجة حالات الاستخدام هذه ولا نحتاج إلى إضافة وظائف مضمنة جديدة أو قبول دلالات محيرة؟" _

إنه سؤال بلاغي لأنني أخطط لتقديم اقتراح كبديل ، وهو اقتراح كنت أتخيله أثناء دراسة هذا الاقتراح وأثناء النظر في جميع عيوبه.

لكني أستطرد ، سيأتي ذلك لاحقًا وهذا التعليق هو سبب الحاجة إلى إعادة النظر في الاقتراح الحالي.

عدم وجود دعم معلن لـ break

قد يبدو هذا وكأنه يخرج من الحقل الأيسر لأن معظم الأشخاص يستخدمون العوائد المبكرة لمعالجة الأخطاء ، لكنني وجدت أنه من الأفضل استخدام break لمعالجة الخطأ في التفاف معظم أو كل func قبل return .

لقد استخدمت هذا النهج لفترة من الوقت وفوائده في تسهيل إعادة البناء وحده تجعله أفضل من return المبكر ، لكن له العديد من المزايا الأخرى بما في ذلك نقطة الخروج الفردية والقدرة على إنهاء قسم من func مبكرًا ولكن لا يزال كذلك قادر على تشغيل التنظيف _ (وهذا على الأرجح هو السبب في أنني نادرًا ما أستخدم defer ، والذي أجد صعوبة في التفكير فيه فيما يتعلق بتدفق البرنامج.) _

لاستخدام break بدلاً من الإرجاع المبكر ، استخدم حلقة for range "1" {...} لإنشاء كتلة للخروج من _ (أقوم بالفعل بإنشاء حزمة تسمى only تحتوي فقط على ثابت يسمى Once بقيمة "1" ): _

func (me *Config) WriteFile() (err error) {
    for range only.Once {
        var j []byte
        j, err = json.MarshalIndent(me, "", "    ")
        if err != nil {
            err = fmt.Errorf("unable to marshal config; %s", 
                err.Error(),
            )
            break
        }
        err = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
        if err != nil {
            err = fmt.Errorf("unable to make directory'%s'; %s", 
                me.GetDir(), 
                err.Error(),
            )
            break
        }
        err = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
        if err != nil {
            err = fmt.Errorf("unable to write to config file '%s'; %s", 
                me.GetFilepath(), 
                err.Error(),
            )
            break
        }
    }
    return err
}

أخطط للتدوين حول هذا النمط مطولًا في المستقبل القريب ، ومناقشة الأسباب العديدة التي جعلتني أجد أنه يعمل بشكل أفضل من العوائد المبكرة.

لكني استطرادا. السبب وراء طرحه هنا هو أنني سأضطر إلى تنفيذ معالجة الأخطاء التي تفترض مبكرًا return s ويتجاهل استخدام break لمعالجة الأخطاء

رأيي err == nil إشكالي

لمزيد من الاستطراد ، أريد أن أثير القلق الذي شعرت به بشأن معالجة الأخطاء الاصطلاحية في Go. على الرغم من أنني أؤمن بشدة بفلسفة Go للتعامل مع الأخطاء عند حدوثها مقابل استخدام معالجة الاستثناءات ، أشعر أن استخدام nil للإشارة إلى عدم وجود خطأ يمثل مشكلة لأنني غالبًا ما أجد أنني أرغب في إرجاع رسالة نجاح من روتين - للاستخدام في استجابات واجهة برمجة التطبيقات (API) - ولا يقوم فقط بإرجاع قيمة غير صفرية فقط عندما يكون هناك خطأ.

لذلك بالنسبة إلى Go 2 ، أود حقًا أن أرى Go فكر في إضافة نوع مضمّن جديد status وثلاث وظائف مضمنة iserror() ، iswarning() ، issuccess() . status يمكن أن ينفذ error - مما يسمح بالكثير من التوافق مع الإصدارات السابقة و nil تم تمريره إلى issuccess() سيعود true - لكن status سيكون لدى nil . سيتيح ذلك شيئًا مثل النهج التالي بدلاً من ذلك:

func (me *Config) WriteFile() (sts status) {
    for range only.Once {
        var j []byte
        j, sts = json.MarshalIndent(me, "", "    ")
        if iserror(sts) {
            sts.AddMessage("unable to marshal config")
            break
        }
        sts = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
        if iserror(sts) {
            sts.AddMessage("unable to make directory'%s'", me.GetDir())
            break
        }
        sts = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
        if iserror(sts) {
            sts.AddMessage("unable to write to config file '%s'", 
                me.GetFilepath(), 
            )
            break
        }
        sts = fmt.Status("config file written")
    }
    return sts
}

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

إذا كنت تعتقد أن هناك أي فرصة لتطوير كود Go الاصطلاحي لهذا النهج ، فيرجى أخذ ذلك في الاعتبار عند تنفيذ معالجة الأخطاء ، بما في ذلك عند النظر في هذا الاقتراح try() .

_ مبرر "ليس للجميع"

كانت إحدى الردود الرئيسية من فريق Go هي _ "مرة أخرى ، لا يحاول هذا الاقتراح حل جميع حالات معالجة الأخطاء." _
وربما يكون هذا هو الشاغل الأكثر إثارة للقلق ، من منظور الحكم.

هل هذا التغيير الجديد المعقد للغة الذي سيتطلب من الجميع تعلم المفاهيم الجديدة يعالج بالفعل عددًا مقنعًا من حالات الاستخدام؟

أليس هذا هو التبرير نفسه الذي رفضه أعضاء الفريق الأساسي للعديد من طلبات الميزات من المجتمع؟ فيما يلي اقتباس مباشر من تعليق أدلى به أحد أعضاء فريق Go في رد نموذجي على طلب ميزة تم إرساله منذ حوالي عامين _ (لا أقوم بتسمية الشخص أو طلب الميزة المحددة لأن هذه المناقشة يجب ألا تكون قادرة الناس ولكن بدلا من اللغة): _

_ "تحتاج ميزة اللغة الجديدة إلى حالات استخدام مقنعة. جميع ميزات اللغة مفيدة ، أو لن يقترحها أحد ؛ السؤال هو: هل هي مفيدة بما يكفي لتبرير تعقيد اللغة ومطالبة الجميع بتعلم المفاهيم الجديدة؟ ما هو الاستخدام المقنع الحالات هنا؟ كيف سيستخدمها الأشخاص؟ على سبيل المثال ، هل يتوقع الناس أن يكونوا قادرين على ... وإذا كان الأمر كذلك فكيف سيفعلون ذلك؟ هل هذا الاقتراح يفعل أكثر من السماح لك ...؟ "_
- عضو أساسي في فريق Go

بصراحة عندما رأيت تلك الردود شعرت بواحد من شعورين:

1. استياء إذا كانت ميزة أتفق معها ، أو
2. الابتهاج إذا كانت ميزة لا أتفق معها.

لكن في كلتا الحالتين كانت مشاعري غير ذات صلة ؛ أفهم وأوافق على أن جزءًا من سبب Go هي اللغة التي يختار الكثير منا تطويرها بسبب تلك الحراسة الغيورة لنقاء اللغة.

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

_ (وآمل حقًا ألا يقوم الفريق بإطلاق النار على الرسول وأن يأخذ هذا على أنه نقد بناء من شخص يريد أن يرى Go يواصل كونه الأفضل لنا جميعًا حيث يجب أن يتم اعتباره "شخصًا غير مرغوب فيه" من قِبل الفريق الأساسي.) _

إذا كان يتطلب مجموعة مقنعة من حالات الاستخدام في العالم الحقيقي هو الشريط لجميع مقترحات الميزات التي ينشئها المجتمع ، ألا يجب أن يكون هو نفس الشريط لـ _ جميع _ مقترحات الميزات؟

تعشيش المحاولة ()

تمت تغطية هذا أيضًا بواسطة عدد قليل ، لكنني أريد إجراء مقارنة بين try() والطلب المستمر للمشغلين الثلاثي. نقلاً عن تعليقات عضو آخر في فريق Go منذ حوالي 18 شهرًا:

_ "عند" البرمجة بشكل كبير "(قواعد التعليمات البرمجية الكبيرة بفرق كبيرة على مدى فترات طويلة من الوقت) ، تتم قراءة الكود بالطريقة أكثر مما تتم كتابته ، لذلك نقوم بالتحسين من أجل سهولة القراءة وليس قابلية الكتابة." _

أحد الأسباب _ الأولية_ المعلنة لعدم إضافة العوامل الثلاثية هو صعوبة قراءتها و / أو إساءة قراءتها عند دمجها. ومع ذلك ، يمكن أن يكون الأمر نفسه صحيحًا بالنسبة لكشوفات try() المتداخلة مثل try(try(try(to()).parse().this)).easily()) .

كانت الأسباب الإضافية للجدل ضد العوامل الثلاثية هي أنها _ "تعبيرات" _ مع هذه الوسيطة القائلة بأن التعبيرات المتداخلة يمكن أن تضيف تعقيدًا. لكن ألا ينشئ try() تعبيرًا متداخلًا أيضًا؟

الآن قال أحدهم هنا _ "أعتقد أن أمثلة مثل [المتداخلة try() s] غير واقعية" _ ولم يتم الطعن في هذا البيان.

ولكن إذا قبل الناس على سبيل الافتراض بأن المطورين لن يقوموا بإدراج try() ، فلماذا لا يتم إعطاء نفس الاحترام للمشغلين الثلاثي عندما يقول الناس _ "أعتقد أن العوامل الثلاثية المتداخلة بعمق غير واقعية؟" _

خلاصة القول لهذه النقطة ، أعتقد أنه إذا كانت الحجة ضد العوامل الثلاثية صحيحة حقًا ، فيجب اعتبارها أيضًا حججًا صالحة ضد هذا الاقتراح try() .

باختصار

في وقت كتابة هذه السطور ، كانت الأصوات السفلية لـ $ 58% لصالح 42% . أعتقد أن هذا وحده يجب أن يكون كافيًا للإشارة إلى أن هذا الاقتراح مثير للانقسام بدرجة كافية ، وقد حان الوقت للعودة إلى لوحة الرسم بشأن هذه المسألة.

fwiw

ملاحظة: لوضعها أكثر في الخد ، أعتقد أننا يجب أن نتبع حكمة يودا المعاد صياغتها:

_ "لا يوجد try() . فقط do() ." _

تضمين التغريدة

beoran ربما يمكنك توسيع العلاقة بين الأدوية الجنيسة ومعالجة الأخطاء.

لا أتحدث باسم beoran ولكن في تعليقي منذ بضع دقائق ، سترى أنه إذا كان لدينا أدوية _ (بالإضافة إلى معلمات الإرجاع المتغيرة) _ فيمكننا بناء try() الخاص بنا.

ومع ذلك - وسأكرر ما قلته أعلاه حول الأدوية الجنسية هنا حيث سيكون من الأسهل رؤيتها:

_ "أعتقد أنه يجب تقليص حالات استخدام الأدوية الجنيسة عن طريق إضافة عناصر مدمجة لمعالجة حالات الاستخدام العامة بدلاً من إضافة الدلالات المربكة وسلطة بناء الجملة للأدوية من Java وآخرون)" _

تضمين التغريدة

عند محاولة صياغة إجابة لسؤالك ، حاولت تنفيذ وظيفة try في Go كما هي ، ومن دواعي سروري أنه من الممكن بالفعل محاكاة شيء مشابه تمامًا:

func try(v interface{}, err error) interface{} {
   if err != nil { 
     panic(err)
   }
   return v
}

انظر هنا كيف يمكن استخدامه: https://play.golang.org/p/Kq9Q0hZHlXL

مساوئ هذا النهج هي:

1. هناك حاجة إلى إنقاذ مؤجل ، ولكن مع try كما في هذا الاقتراح ، هناك حاجة أيضًا إلى معالج مؤجل إذا أردنا القيام بمعالجة الأخطاء بشكل صحيح. لذلك أشعر أن هذا ليس جانبًا سلبيًا خطيرًا. قد يكون من الأفضل أن يكون لدى Go نوع من super(arg1, ..., argn) مدمج يتسبب في عودة المتصل ، بمستوى أعلى في مكدس الاستدعاءات ، بالوسيطات المعطاة arg1 ، ... argn ، نوع من الإرجاع الفائق إن شئت.
2. هذا try الذي قمت بتنفيذه يمكنه العمل فقط مع دالة تقوم بإرجاع نتيجة واحدة وخطأ.
3. يجب عليك كتابة تأكيد نتائج واجهة emtpy التي تم إرجاعها.

يمكن للأدوية القوية بشكل كافٍ أن تحل المشكلة 2 و 3 ، مع ترك 1 فقط ، والذي يمكن حله بإضافة super() . مع هاتين الميزتين ، يمكننا الحصول على شيء مثل:

func (T ... interface{})try(T, err error) super {
   if err != nil { 
      super(err)
   }
  super(T...)
}

وبعد ذلك لن تكون هناك حاجة إلى الإنقاذ المؤجل بعد الآن. ستكون هذه الميزة متاحة حتى إذا لم تتم إضافة الأدوية الجنيسة إلى Go.

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

beoran من الجيد أن نرى أننا توصلنا إلى نفس القيود تمامًا بشكل مستقل فيما يتعلق بتنفيذ try() في userland ، باستثناء الجزء الممتاز الذي لم أدرجه لأنني أردت التحدث عن شيء مشابه في اقتراح بديل. :-)

يعجبني الاقتراح ولكن حقيقة أنه كان عليك تحديد صراحة أن defer try(...) و go try(...) غير مسموح بهما جعلني أعتقد أن شيئًا ما لم يكن صحيحًا تمامًا ... التعامد هو دليل تصميم جيد. لمزيد من القراءة ورؤية أشياء مثل
x = try(foo(...)) y = try(bar(...))
أتساءل عما إذا كان قد يكون try يحتاج إلى سياق ! انصح:
try ( x = foo(...) y = bar(...) )
هنا ترجع قيمتا foo() و bar() قيمتين ، والثانية هي error . جرب الدلالات المهمة فقط للمكالمات داخل الكتلة try حيث يتم حذف قيمة الخطأ المُعاد (بدون مُستقبل) بدلاً من تجاهلها (المتلقي هو _ ). يمكنك حتى معالجة بعض الأخطاء بين foo و bar للمكالمات.

ملخص:
أ) مشكلة عدم السماح بـ try لـ go و defer تختفي بحكم التركيب.
ب) يمكن معالجة الخطأ في معالجة الوظائف المتعددة.
ج) يتم التعبير عن طبيعتها السحرية بشكل أفضل على أنها بناء جملة خاص بدلاً من استدعاء دالة.

إذا كانت المحاولة عبارة عن سياق ، فقد قمنا للتو بإعداد كتل المحاولة / الالتقاط التي نحاول على وجه التحديد تجنبها (ولسبب وجيه)

لا يوجد صيد. سيتم إنشاء نفس الرمز بالضبط كما هو الحال عندما يكون الاقتراح الحالي
x = try(foo(...)) y = try(bar(...))
هذا مجرد بناء جملة مختلف ، وليس دلالات.
""

أعتقد أنني وضعت بعض الافتراضات حول هذا الموضوع والتي لم يكن يجب أن أفعلها ، على الرغم من أنه لا يزال هناك عيبان في ذلك.

ماذا لو لم تُرجع foo أو bar خطأً ، فهل يمكن وضعها في سياق try أيضًا؟ إذا لم يكن الأمر كذلك ، يبدو أنه سيكون من القبيح نوعًا ما التبديل بين وظائف الخطأ والوظائف غير المتعلقة بالخطأ ، وإذا كان بإمكانهم ذلك ، فإننا نعود إلى مشكلات تجربة الكتل في اللغات القديمة.

الشيء الثاني هو أن بناء الجملة keyword ( ... ) يعني أنك تسبق الكلمة الأساسية في كل سطر. لذلك بالنسبة للاستيراد ، var ، const ، إلخ: يبدأ كل سطر بالكلمة الرئيسية. إجراء استثناء لهذه القاعدة لا يبدو قرارًا جيدًا

بدلاً من استخدام دالة ، هل سيكون الأمر أكثر اصطلاحًا باستخدام معرف خاص؟

لدينا بالفعل المعرف الفارغ _ الذي يتجاهل القيم.
يمكن أن يكون لدينا شيء مثل # والذي لا يمكن استخدامه إلا في الوظائف التي تحتوي على آخر قيمة تم إرجاعها من نوع الخطأ.

func foo() (error) {
    f, # := os.Open()
    defer f.Close()
    _, # = f.WriteString("foo")
    return nil
}

عند تعيين خطأ إلى # ، تعود الدالة فورًا مع تلقي الخطأ. أما بالنسبة للمتغيرات الأخرى ، فستكون قيمها:

• إذا لم يتم تسميتها بقيمة صفرية
• القيمة المخصصة للمتغيرات المسماة بخلاف ذلك

deanveloper ، دلالات الكتلة try مهمة فقط للوظائف التي تُرجع قيمة خطأ وحيث لا يتم تعيين قيمة الخطأ. لذلك يمكن أيضًا كتابة المثال الأخير على الاقتراح الحالي بصيغة
try(x = foo(...)) try(y = bar(...))
وضع كلا العبارتين في نفس الكتلة يشبه ما نقوم به من أجل الكشوف المتكررة import ، const و var .

الآن إذا كان لديك ، على سبيل المثال
try( x = foo(...)) go zee(...) defer fum() y = bar(...) )
هذا يعادل الكتابة
try(x = foo(...)) go zee(...) defer fum() try(y = bar(...))
إن احتساب كل ذلك في كتلة محاولة واحدة يجعله أقل انشغالًا.

انصح
try(x = foo())
إذا لم يُرجع foo () قيمة خطأ ، فهذا يعادل
x = foo()

انصح
try(f, _ := os.open(filename))
نظرًا لتجاهل قيمة الخطأ المرتجعة ، فإن هذا يعادل فقط
f, _ := os.open(filename)

انصح
try(f, err := os.open(filename))
نظرًا لعدم تجاهل قيمة الخطأ الذي تم إرجاعه ، فهذا يعادل
f, err := os.open(filename) if err != nil { return ..., err }
كما هو محدد حاليا في الاقتراح.

كما أنه يزيل المحاولات المتداخلة بشكل جيد!

فيما يلي رابط إلى الاقتراح البديل الذي ذكرته أعلاه:

• https://github.com/golang/go/issues/32473

يدعو إلى إضافة ميزتين (2) صغيرتين لكن للأغراض العامة لمعالجة حالات الاستخدام نفسها مثل try()

1. القدرة على استدعاء func / إغلاق في بيان التخصيص.
2. القدرة على break ، continue أو return أكثر من مستوى واحد.

مع هاتين الميزتين لن يكونا _ "سحريتين" _ وأعتقد أن استخدامهما سينتج رمز Go الذي يسهل فهمه وأكثر انسجامًا مع كود Go الاصطلاحي الذي نعرفه جميعًا.

لقد قرأت الاقتراح وأعجبني حقًا إلى أين تتجه المحاولة.

بالنظر إلى مدى انتشار المحاولة ، أتساءل عما إذا كان جعلها سلوكًا افتراضيًا أكثر سيجعل التعامل معها أسهل.

ضع في اعتبارك الخرائط. هذا صحيح:

v := m[key]

هكذا:

v, ok := m[key]

ماذا لو تعاملنا مع الأخطاء تمامًا بالطريقة التي تقترحها المحاولة ، لكن أزلنا المضمنة. لذلك إذا بدأنا بـ:

v, err := fn()

بدلا من الكتابة:

v := try(fn())

يمكننا بدلاً من ذلك أن نكتب:

v := fn()

عندما لا يتم تسجيل قيمة الخطأ ، يتم التعامل معها تمامًا كما تفعل المحاولة. قد يستغرق التعود قليلاً ، لكنه يبدو مشابهًا جدًا لـ v, ok := m[key] و v, ok := x.(string) . بشكل أساسي ، يؤدي أي خطأ غير معالج إلى إرجاع الوظيفة وتعيين قيمة الخطأ.

للعودة إلى استنتاجات مستندات التصميم ومتطلبات التنفيذ:

• يتم الاحتفاظ بصيغة اللغة ولا يتم إدخال كلمات رئيسية جديدة
• لا يزال السكر النحوي مثل المحاولة ونأمل أن يكون من السهل شرحه.
• لا يتطلب بناء جملة جديدة
• يجب أن يكون متوافقًا تمامًا مع الإصدارات السابقة.

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

لذا باستخدام المثال CopyFile من الاقتراح مع defer fmt.HandleErrorf(&err, "copy %s %s", src, dst) ، نحصل على:

func CopyFile(src, dst string) (err error) {
        defer fmt.HandleErrorf(&err, "copy %s %s", src, dst)

        r := os.Open(src)
        defer r.Close()

        w := os.Create(dst)
        defer func() {
                err := w.Close()
                if err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        io.Copy(w, r)
        w.Close()
        return nil
}

savaki ، لقد أحببت هذا وكنت أفكر في ما يتطلبه الأمر لجعل Go يقلب معالجة الخطأ من خلال معالجة الأخطاء دائمًا بشكل افتراضي والسماح للمبرمج بتحديد متى لا يفعل ذلك (من خلال التقاط الخطأ في متغير) ولكن الافتقار التام لأي شيء المعرف سيجعل من الصعب متابعة الكود لأن المرء لن يكون قادرًا على رؤية جميع نقاط الإرجاع. قد يكون اصطلاحًا لتسمية الوظائف التي يمكن أن تعرض خطأ بشكل مختلف يمكن أن تعمل (مثل كتابة المعرفات العامة بأحرف كبيرة). قد يكون ذلك في حالة عرض دالة لخطأ ، يجب أن تنتهي دائمًا بـ ، دعنا نقول ? . ثم يمكن لـ Go دائمًا معالجة الخطأ ضمنيًا وإعادته تلقائيًا إلى وظيفة الاستدعاء تمامًا مثل try. هذا يجعله مشابهًا جدًا لبعض المقترحات التي تقترح استخدام معرف ? بدلاً من المحاولة ولكن الاختلاف المهم هنا هو أن ? سيكون جزءًا من اسم الوظيفة وليس معرفًا إضافيًا. في الواقع ، لن يتم تجميع الوظيفة التي أعادت error كقيمة إرجاع أخيرة إذا لم يتم لصقها ? . بالطبع ? تعسفي ويمكن استبداله بأي شيء آخر يجعل النية أكثر وضوحًا. سيكون operation?() معادلاً للالتفاف try(someFunc()) لكن ? سيكون جزءًا من اسم الوظيفة وسيكون الغرض الوحيد منه هو الإشارة إلى أن الوظيفة يمكنها إرجاع خطأ تمامًا مثل الكتابة بالأحرف الكبيرة الحرف الأول من المتغير.

ينتهي هذا الأمر بشكل سطحي بأن يكون مشابهًا جدًا للمقترحات الأخرى التي تطلب استبدال try بـ ? لكن الاختلاف الجوهري هو أنه يجعل معالجة الخطأ ضمنيًا (تلقائي) وبدلاً من ذلك يجعل تجاهل (أو التفاف) أخطاء واضحة والتي نوع من أفضل الممارسات على أي حال. المشكلة الأكثر وضوحًا في هذا بالطبع هي أنه غير متوافق مع الإصدارات السابقة وأنا متأكد من وجود المزيد.

ومع ذلك ، سأكون مهتمًا جدًا برؤية كيف يمكن لـ Go أن يخطئ في معالجة الحالة الافتراضية / الضمنية عن طريق أتمتة والسماح للمبرمج بكتابة القليل من التعليمات البرمجية الإضافية لتجاهل / تجاوز المعالجة. التحدي الذي أعتقده هو كيفية جعل جميع نقاط العودة واضحة في هذه الحالة لأنه بدونها ستصبح الأخطاء أشبه بالاستثناءات بمعنى أنها يمكن أن تأتي من أي مكان لأن تدفق البرنامج لن يجعل الأمر واضحًا. يمكن للمرء أن يقول أن ارتكاب أخطاء ضمنية باستخدام المؤشر المرئي هو نفسه تنفيذ try وجعل errcheck فشلًا في المترجم.

هل يمكننا عمل شيء مثل استثناءات c ++ مع أدوات التزيين للوظائف القديمة؟

func some_old_test() (int, error){
    return 0, errors.New("err1")
}
func some_new_test() (int){
        if true {
             return 1
        }
    throw errors.New("err2")
}
func throw_res(int, e error) int {
    if e != nil {
        throw e
    }
    return int
}
func main() {
    fmt.Println("Hello, playground")
    try{
        i := throw_res(some_old_test())
        fmt.Println("i=", i + some_new_test())
    } catch(err io.Error) {
        return err
    } catch(err error) {
        fmt.Println("unknown err", err)
    }
}

owais كنت أفكر في أن الدلالات ستكون تمامًا مثل المحاولة ، لذا على الأقل ستحتاج إلى التصريح عن نوع الخطأ. لذلك إذا بدأنا بـ:

func foo() error {
  _, err := fn() 
  if err != nil {
    return err
  }

  return nil
} 

إذا فهمت اقتراح المحاولة ، فما عليك سوى القيام بذلك:

func foo() error {
  _  := fn() 
  return nil
} 

لن يتم تجميعها. من المزايا الرائعة أنه يمنح المترجم فرصة لإخبار المستخدم بما ينقصه. هناك شيء يشير إلى أن استخدام معالجة الخطأ الضمني يتطلب تسمية نوع إرجاع الخطأ ، يخطئ.

هذا بعد ذلك ، من شأنه أن يعمل:

func foo() (err error) {
  _  := fn() 
  return nil
} 

لماذا لا نتعامل فقط مع حالة الخطأ التي لم يتم تعيينها إلى متغير.

• إزالة الحاجة إلى العوائد المسماة ، يمكن للمترجم أن يفعل كل ذلك بمفرده.
• يسمح بإضافة سياق.
• يتعامل مع حالة الاستخدام الشائع.
• متوافق مع الجيل السابق
• لا يتفاعل بشكل غريب مع التأجيل أو الحلقات أو المفاتيح.

عودة ضمنية لحالة if err! = nil ، يمكن للمجمع إنشاء اسم متغير محلي للإرجاع إذا لزم الأمر لا يمكن للمبرمج الوصول إليه.
أنا شخصيا لا أحب هذه الحالة بالذات من نقطة الوقوف لسهولة قراءة الكود

f := os.Open("foo.txt")

تفضل عائدًا صريحًا ، يتبع الكود قراءة أكثر من المانترا المكتوبة

f := os.Open("foo.txt") else return

من المثير للاهتمام أنه يمكننا قبول كلا النموذجين ، وجعل gofmt يضيف عائد else تلقائيًا.

إضافة سياق ، وكذلك تسمية محلية للمتغير. تصبح العودة صريحة لأننا نريد إضافة سياق.

f := os.Open("foo.txt") else err {
  return errors.Wrap(err, "some context")
}

إضافة سياق بقيم إرجاع متعددة

f := os.Open("foo.txt") else err {
  return i, j, errors.Wrap(err, "some context")
}

تتطلب الدوال المتداخلة أن تعالج الوظائف الخارجية جميع النتائج بنفس الترتيب
ناقص الخطأ النهائي.

bits := ioutil.ReadAll(os.Open("foo")) else err {
  // either error ends up here.
  return i, j, errors.Wrap(err, "some context")
}

المترجم يرفض التجميع بسبب فقدان قيمة إرجاع الخطأ في الوظيفة

func foo(s string) int {
   i := strconv.Atoi(s) // cannot implicitly return error due to missing error return value for foo.
   return i * 2
}

يجمع لحسن الحظ لأنه يتم تجاهل الخطأ صراحة.

func foo(s string) int {
   i, _ := strconv.Atoi(s)
   return i * 2
} 

المترجم سعيد. يتجاهل الخطأ كما هو الحال حاليًا بسبب عدم حدوث أي تعيين أو لاحقة أخرى.

func foo() error {
  return errors.New("whoops")
}

func bar() {
  foo()
}

داخل حلقة يمكنك استخدام متابعة.

for _, s := range []string{"1","2","3","4","5","6"} {
  i := strconv.Atoi(s) else continue
}

تحرير: استبدلت ; بـ else

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

أكبر جانب سلبي لما تقترحه هو أنه لا يعرض جميع النقاط من حيث يمكن أن تعود الوظيفة على عكس if err != nil {return err} الحالي أو وظيفة try التي تم تقديمها في هذا الاقتراح. على الرغم من أنه سيعمل بنفس الطريقة تمامًا تحت الغطاء ، إلا أن الكود سيبدو بصريًا مختلفًا تمامًا. عند قراءة الكود ، لن تكون هناك طريقة لمعرفة استدعاءات الوظائف التي قد تؤدي إلى حدوث خطأ. سينتهي الأمر بأن تكون تجربة أسوأ من استثناءات المنظمة البحرية الدولية.

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

العيب الرئيسي لهذا النهج هو أن معلمة نتيجة الخطأ تحتاج إلى تسمية ، مما قد يؤدي إلى واجهات برمجة تطبيقات أقل جمالًا (لكن راجع الأسئلة الشائعة حول هذا الموضوع). نعتقد أننا سنعتاد عليه بمجرد أن يثبت هذا الأسلوب نفسه.

لست متأكدًا مما إذا كان قد تم اقتراح شيء كهذا من قبل ، أو لا يمكنك العثور عليه هنا أو في الاقتراح. هل فكرت في دالة مضمنة أخرى تُرجع مؤشرًا لقيمة إرجاع الخطأ للوظيفة الحالية؟
على سبيل المثال:

func example() error {
        var err *error = funcerror() // always return a non-nil pointer
        fmt.Print(*err) // always nil if the return parameters are not named and not in a defer

        defer func() {
                err := funcerror()
                fmt.Print(*err) // "x"
        }

        return errors.New("x")
}

func exampleNamed() (err error) {
        funcErr := funcerror()
        fmt.Print(*funcErr) // "nil"

        err = errors.New("x")
        fmt.Print(*funcErr) // "x", named return parameter is reflected even before return is called

        *funcErr = errors.New("y")
        fmt.Print(err) // "y", unfortunate side effect?

        defer func() {
                funcErr := funcerror()
                fmt.Print(*funcErr) // "z"
                fmt.Print(err) // "z"
        }

        return errors.New("z")
}

الاستخدام مع المحاولة:

func CopyFile(src, dst string) (error) {
        defer func() {
                err := funcerror()
                if *err != nil {
                        *err = fmt.Errorf("copy %s %s: %v", src, dst, err)
                }
        }()
        // one liner alternative
        // defer fmt.HandleErrorf(funcerror(), "copy %s %s", src, dst)

        r := try(os.Open(src))
        defer r.Close()

        w := try(os.Create(dst))
        defer func() {
                w.Close()
                err := funcerror()
                if *err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        try(io.Copy(w, r))
        try(w.Close())
        return nil
}

وبدلاً من ذلك ، فإن funcerror (الاسم هو عمل قيد التنفيذ: D) يمكن أن يعود بلا شيء إذا لم يتم استدعاؤه بالداخل تأجيل.

البديل الآخر هو أن funcerror إرجاع واجهة "Errorer" لجعلها للقراءة فقط:

type interface Errorer() {
        Error() error
}

savaki أنا في الواقع أحب اقتراحك بحذف try() والسماح له بأن يكون أشبه باختبار خريطة أو تأكيد نوع. هذا يشعر أكثر بكثير _ "Go-like." _

ومع ذلك ، لا تزال هناك مشكلة صارخة واحدة أراها ، وهذا هو اقتراحك الذي يفترض أن جميع الأخطاء باستخدام هذا الأسلوب ستؤدي إلى return وتترك الوظيفة. ما لا يفكر فيه هو إصدار break من for الحالي أو continue الحالي for .

في وقت مبكر return s عبارة عن مطرقة ثقيلة عندما يكون المشرط في كثير من الأحيان هو الخيار الأفضل.

لذلك أؤكد أن break و continue يجب أن يكونا إستراتيجيتين صالحتين لمعالجة الأخطاء وحاليًا لا يفترض اقتراحك سوى return بينما try() يفترض ذلك أو استدعاء خطأ المعالج نفسه يمكنه فقط return ، وليس break أو continue .

يبدو أن سافاكي وكان لدي أفكار مماثلة ، لقد أضفت للتو دلالات الكتلة للتعامل مع الخطأ إذا رغبت في ذلك. على سبيل المثال إضافة comtext ، للحلقات حيث تريد ماس كهربائى وما إلى ذلك

mikeschinkel انظر إلى امتدادي ، كان لدي هو وأنا أفكار متشابهة ، لقد قمت للتو بتوسيعها ببيان كتلة اختياري

@ جيمس لورانس

mikesckinkel انظر إلى الامتداد الخاص بي ، لقد كان لدي وأنا أفكار متشابهة ، لقد قمت للتو بتوسيعها ببيان كتلة اختياري

أخذ المثال الخاص بك:

f := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

والذي يقارن بما نقوم به اليوم:

f,err := os.Open("foo.txt"); 
if err != nil {
  return errors.Wrap(err, "some context")
}

هو بالتأكيد الأفضل بالنسبة لي. باستثناء أنه يحتوي على بعض المشكلات:

1. يبدو أن err _ تم إعلانه _ "بطريقة سحرية". يجب التقليل من السحر ، أليس كذلك؟ لذلك دعونا نعلن ذلك:

f, err := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

1. لكن هذا لا يزال لا يعمل لأن Go لا يفسر قيم nil على أنها false ولا قيم المؤشر كـ true ، لذلك يجب أن يكون:

f, err := os.Open("foo.txt"); err != nil {
  return errors.Wrap(err, "some context")
}

وما ينجح ، يبدأ في الشعور بنفس القدر من العمل والكثير من بناء الجملة في سطر واحد ، لذلك قد أستمر في القيام بالطريقة القديمة من أجل الوضوح.

ولكن ماذا لو أضاف Go اثنين (2) من المباني ؛ iserror() و error() ؟ ثم يمكننا القيام بذلك ، وهذا لا أشعر بالسوء بالنسبة لي:

f := os.Open("foo.txt"); iserror() {
  return errors.Wrap(error(), "some context")
}

أو أفضل _ (شيء من هذا القبيل): _

f := os.Open("foo.txt"); iserror() {
  return error().Extend("some context")
}

ماذا تعتقد والآخرين؟

جانبا ، تحقق من هجاء اسم المستخدم الخاص بي. لم يتم إخطاري بذكرك إذا لم أكن منتبهًا على أي حال ...

mikeschinkel آسف على الاسم الذي كنت على هاتفي ولم يكن جيثب يقترح تلقائيًا.

يبدو أنه تم التصريح عن الخطأ "بطريقة سحرية". يجب التقليل من السحر ، أليس كذلك؟ لذلك دعونا نعلن ذلك:

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

أنا سعيد بشكل عام بمعالجة أخطاء go's مع الإضافات القادمة لحزمة الأخطاء. لا أرى أي شيء في هذا الاقتراح مفيد للغاية. أنا فقط أحاول تقديم أكثر ملاءمة طبيعية لـ golang إذا كنا قد انتهينا من القيام بذلك.

_ "إن فكرة إدراج المرتجعات تلقائيًا هي فكرة سحرية." _

لن تحصل على أي جدال مني هناك.

_ "ليس هذا هو الشيء الأكثر سحراً في هذا الاقتراح بأكمله." _

أعتقد أنني كنت أحاول أن أجادل في أن _ "كل السحر يمثل مشكلة." _

_ "بالإضافة إلى أنني سأجادل بأن الخطأ قد تم الإعلان عنه ؛ فقط في النهاية داخل سياق الكتلة المحددة النطاق ..." _

لذا إذا أردت أن أسميها err2 فهل هذا يعمل أيضًا؟

f := os.Open("foo.txt"); err2 {
  return errors.Wrap(err, "some context")
}

لذلك أفترض أنك تقترح أيضًا معالجة حالة خاصة لـ err / err2 بعد الفاصلة المنقوطة ، أي أنه من المفترض أن تكون إما nil أو لا nil بدلاً من bool مثل عند فحص الخريطة؟

if _,ok := m[a]; !ok {
   print("there is no 'a' in 'm'")
}

أنا سعيد بشكل عام بمعالجة أخطاء go's مع الإضافات القادمة لحزمة الأخطاء.

أنا سعيد أيضًا بمعالجة الأخطاء ، عند دمجها مع break و continue _ (لكن ليس return .) _

كما هو الحال ، أرى أن هذا الاقتراح try() أكثر ضررًا من كونه مفيدًا ، وأفضّل ألا أرى شيئًا سوى هذا التنفيذ كما هو مقترح. # ج.

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

نعم ، يمكننا استخدام الأدوية الجنيسة (نسخة من الأدوية العامة أقوى بكثير من تلك الموجودة في مسودة التصميم على https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md) لكتابة وظيفة هذا الذعر على الخطأ. لكن الذعر من الخطأ ليس من النوع الذي يكتبه مبرمجو Go اليوم ، ولا يبدو أنه فكرة جيدة بالنسبة لي.

المعالجة الخاصة لـmikeschinkel هي أن الكتلة يتم تنفيذها فقط عندما يكون هناك خطأ.
""
f: = os.Open ('foo') ؛ الخطأ {إرجاع الخطأ} // سيكون دائمًا غير معدوم هنا.

تضمين التغريدة

_ "نعم ، يمكننا استخدام الأدوية الجنيسة ... لكن الذعر من الخطأ ليس نوع معالجة الأخطاء الذي يكتبه مبرمجو Go اليوم ، ولا يبدو أنه فكرة جيدة بالنسبة لي." _

أنا أتفق معك بشدة في هذا الأمر ، وبالتالي يبدو أنك قد أساءت تفسير القصد من تعليقي. لم أكن أقترح على الإطلاق أن يقوم فريق Go بتنفيذ معالجة الأخطاء التي تستخدم panic() - بالطبع لا.

بدلاً من ذلك ، كنت أحاول فعلاً متابعة تقدمك من العديد من تعليقاتك السابقة حول قضايا أخرى واقترحت أن نتجنب إجراء أي تغييرات على Go ليست ضرورية تمامًا لأنها ممكنة بدلاً من ذلك في userland . إذاً _if_ تمت معالجة الأدوية الجنيسة _ ثم يمكن للأشخاص الذين يريدون try() تنفيذها بأنفسهم ، وإن كان ذلك من خلال الاستفادة من panic() . وستكون هذه ميزة أقل سيحتاج الفريق إلى إضافتها وتوثيقها لـ Go.

ما لم أفعله - وربما لم يكن ذلك واضحًا - كان يدافع عن أن يستخدم الأشخاص بالفعل panic() لتنفيذ try() ، فقط يمكنهم ذلك إذا أرادوا حقًا ، وكان لديهم ميزات الأدوية.

هل هذا يوضح؟

بالنسبة لي ، فإن الاتصال بـ panic ، ومع ذلك ، يختلف تمامًا عن هذا الاقتراح لـ try . لذا ، بينما أعتقد أنني أفهم ما تقوله ، فأنا لا أوافق على أنهما متكافئان. حتى لو كان لدينا أدوية قوية بما يكفي لتنفيذ إصدار try هذا الذعر ، أعتقد أنه لا تزال هناك رغبة معقولة في إصدار try المقدم في هذا الاقتراح.

ianlancetaylor تم الإقرار به. مرة أخرى ، كنت أبحث عن سبب عدم الحاجة إلى إضافة try() بدلاً من إيجاد طريقة لإضافته. كما قلت أعلاه ، أفضل ألا يكون لدي أي شيء جديد لمعالجة الأخطاء من أن يكون لدي try() كما هو مقترح هنا.

أنا شخصياً أحببت الاقتراح السابق check أكثر من هذا ، بناءً على الجوانب المرئية البحتة ؛ كان لدى check نفس القوة مثل try() لكن bar(check foo()) أكثر قابلية للقراءة بالنسبة لي من bar(try(foo())) (كنت فقط بحاجة إلى ثانية لحساب الأقواس!).

والأهم من ذلك ، أن ما استحوذت عليه بشأن handle / check هو أنه لا يسمح بتغليف الشيكات الفردية بطرق مختلفة - والآن هذا الاقتراح try() له نفس الخلل ، أثناء استدعاء ميزات مربكة للمبتدئين ونادراً ما تستخدم للمبتدئين والعائدات المسماة. ومع handle على الأقل ، كان لدينا خيار استخدام النطاقات لتحديد كتل المقابض ، مع defer حتى أن هذا غير ممكن.

بقدر ما أشعر بالقلق ، فإن هذا الاقتراح يخسر أمام الاقتراح السابق handle / check في جميع الجوانب.

إليك مصدر قلق آخر بشأن استخدام المؤجِّلات لمعالجة الأخطاء.

try هو خروج مقصود / متحكم فيه من دالة. يعمل defers دائمًا ، بما في ذلك عمليات الخروج غير المنضبطة / غير المقصودة من الوظائف. قد يؤدي عدم التطابق إلى حدوث ارتباك. إليك سيناريو وهمي:

func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

تذكر أن net / http يتعافى من الذعر ، وتخيل تصحيح مشكلة إنتاج حول الذعر. ستنظر إلى الأجهزة الخاصة بك وترى ارتفاعًا مفاجئًا في حالات فشل مكالمات db ، من المكالمات recordMetric . قد يخفي هذا المشكلة الحقيقية ، وهي الذعر في السطر التالي.

لست متأكدًا من مدى خطورة هذا القلق في الممارسة العملية ، ولكن (للأسف) ربما يكون سببًا آخر للاعتقاد بأن التأجيل ليس آلية مثالية للتعامل مع الأخطاء.

إليك تعديل قد يساعد في حل بعض المخاوف المثارة: تعامل مع try مثل goto بدلاً من مثل return . أستمع لي. :)

بدلاً من ذلك ، سيكون try سكرًا نحويًا لـ:

t1, … tn, te := f()  // t1, … tn, te are local (invisible) temporaries
if te != nil {
        err = te   // assign te to the error result parameter
        goto error // goto "error" label
}
x1, … xn = t1, … tn  // assignment only if there was no error

فوائد:

• defer غير مطلوب لتزيين الأخطاء. (لا تزال عمليات الإرجاع المسماة مطلوبة ، على الرغم من ذلك).
• وجود التسمية error: هو دليل مرئي على وجود try في مكان ما في الوظيفة.

يوفر هذا أيضًا آلية لإضافة المعالجات التي تتجنب مشاكل المعالج كوظيفة: استخدم التسميات كمعالجات. try(fn(), wrap) سيكون goto wrap بدلاً من goto error . يستطيع المترجم تأكيد وجود wrap: في الوظيفة. لاحظ أن وجود معالجات يساعد أيضًا في تصحيح الأخطاء: يمكنك إضافة / تعديل المعالج لتوفير مسار تصحيح الأخطاء.

عينة من الرموز:

func CopyFile(src, dst string) (err error) {
    r := try(os.Open(src))
    defer r.Close()

    w := try(os.Create(dst))
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “try” fails
        }
    }()

    try(io.Copy(w, r), copyfail)
    try(w.Close())
    return nil

error:
    return fmt.Errorf("copy %s %s: %v", src, dst, err)

copyfail:
    recordMetric("copy failure") // count incidents of this failure
    return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

تعليقات أخرى:

• قد نطلب أن يسبق أي تصنيف يستخدم كهدف لـ try بيان إنهاء. في الممارسة العملية ، هذا سيجبرهم على نهاية الوظيفة ويمكن أن يمنع بعض كود السباغيتي. من ناحية أخرى ، قد يمنع بعض الاستخدامات المعقولة والمفيدة.
• يمكن استخدام try لإنشاء حلقة. أعتقد أن هذا يندرج تحت شعار "إذا كان هذا مؤلمًا ، فلا تفعله" ، لكنني لست متأكدًا.
• قد يتطلب ذلك إصلاح https://github.com/golang/go/issues/26058.

الائتمان: أعتقد أن البديل من هذه الفكرة قد اقترحه griesemer شخصيًا في GopherCon العام الماضي.

josharian التفكير في التفاعل مع panic مهم هنا ، ويسعدني أنك طرحته ، لكن مثالك يبدو غريبًا بالنسبة لي. في الكود التالي ، ليس من المنطقي بالنسبة لي أن المؤجل يسجل دائمًا مقياسًا "db call failed" . سيكون مقياسًا خاطئًا إذا نجح someHTTPHandlerGuts وأرجع nil . يتم تشغيل defer في جميع حالات الخروج ، وليس فقط حالات الخطأ أو الذعر ، لذا يبدو الرمز خاطئًا حتى لو لم يكن هناك ذعر.

func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

josharian نعم ، هذا هو الإصدار الذي ناقشناه العام الماضي بشكل أو بآخر (باستثناء أننا استخدمنا check بدلاً من try ). أعتقد أنه سيكون من الأهمية بمكان ألا يتمكن المرء من القفز "للخلف" إلى بقية الجسم الوظيفي ، بمجرد أن نكون عند التصنيف error . سيضمن ذلك أن goto "منظم" إلى حد ما (لا يوجد رمز معكرونة ممكن). كان أحد المخاوف التي تم طرحها هو أن معالج الخطأ (التسمية error: ) سينتهي به المطاف دائمًا في نهاية الوظيفة (وإلا فسيتعين على المرء القفز حوله بطريقة ما). أنا شخصياً أحب التعامل مع رمز الخطأ بعيدًا (في النهاية) ، لكن آخرين شعروا أنه يجب أن يكون مرئيًا في البداية.

mikeshenkel أرى العودة من الحلقة على أنها علامة زائد وليست سلبية. أعتقد أن ذلك سيشجع المطورين على استخدام وظيفة منفصلة للتعامل مع محتويات حلقة أو استخدام خطأ بشكل صريح كما نفعل حاليًا. كلاهما يبدو نتائج جيدة بالنسبة لي.

من وجهة نظري ، لا أشعر أن بناء الجملة هذا يجب أن يتعامل مع كل حالة استخدام تمامًا مثلما لا أشعر أنني بحاجة إلى استخدام

الخامس ، حسنًا: = م [مفتاح]

شكل من القراءة من الخريطة

يمكنك تجنب فرض تسميات الانتقال إلى نهاية الوظيفة عن طريق إحياء اقتراح handle / check في شكل مبسط. ماذا لو استخدمنا بناء الجملة handle err { ... } لكننا لم نسمح فقط لسلسلة المعالجات ، بدلاً من ذلك يتم استخدام آخر واحد فقط. إنه يبسط هذا الاقتراح كثيرًا ، وهو مشابه جدًا لفكرة الانتقال ، إلا أنه يجعل المناولة أقرب إلى نقطة الاستخدام.

func CopyFile(src, dst string) (err error) {
    handle err {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    r := check os.Open(src)
    defer r.Close()

    w := check os.Create(dst)
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “check” fails
        }
    }()

    {
        // handlers are scoped, after this scope the original handle is used again.
        // as an alternative, we could have repeated the first handle after the io.Copy,
        // or come up with a syntax to name the handlers, though that's often not useful.
        handle err {
            recordMetric("copy failure") // count incidents of this failure
            return fmt.Errorf("copy %s %s: %v", src, dst, err)
        }
        check io.Copy(w, r)
    }
    check w.Close()
    return nil
}

على سبيل المكافأة ، هذا له مسار مستقبلي للسماح بسلسلة المعالجات ، حيث سيكون لجميع الاستخدامات الحالية عائد.

joshariangriesemer إذا أدخلت معالجات مسماة (والتي طلبت العديد من الاستجابات للتحقق / التعامل معها ، راجع السمات المتكررة ) ، فهناك خيارات بناء الجملة مفضلة على try(f(), err) :

try.err f()
try?err f()
try#err f()

?err    f() // because 'try' is redundant
?return f() // no handler
?panic  f() // no handler

(?err f()).method()

f?err() // lead with function name, instead of error handling
f?err().method()

file, ?err := os.Open(...) // many check/handle responses also requested this style

من أكثر الأشياء التي أحبها في Go هو أن تركيبها خالي نسبيًا من علامات الترقيم ، ويمكن قراءتها بصوت عالٍ دون مشاكل كبيرة. أنا أكره حقًا أن ينتهي الأمر بـ Go كـ $#@!perl .

بالنسبة لي ، فإن إنشاء وظيفة مضمنة "جرب" وتمكين السلاسل له مشكلتان:

• إنه غير متسق مع بقية تدفق التحكم أثناء التشغيل (على سبيل المثال ، للكلمات الرئيسية / if / return / etc).
• يجعل الكود أقل قابلية للقراءة.

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

العامل الثلاثي هو مكان آخر لا يحتوي على شيء ويتطلب المزيد من ضغطات المفاتيح ولكنه في نفس الوقت يحسن إمكانية القراءة / الصيانة. ستؤدي إضافة "try" في هذا النموذج الأكثر تقييدًا إلى موازنة التعبيرية مقابل المقروئية بشكل أفضل ، IMO.

يؤثر FWIW ، panic على تدفق التحكم وله أقواس ، لكن go و defer يؤثران أيضًا على التدفق ولا يؤثران. أميل إلى الاعتقاد بأن try أكثر شبهاً بـ defer من حيث إنها عملية تدفق غير عادية وتجعل من الصعب القيام بـ try (try os.Open(file)).Read(buf) أمر جيد لأننا نريد تثبيط الخطوط المفردة على أي حال ، ولكن أيا كان. كلاهما بخير.

اقتراح سيكره الجميع بسبب الاسم الضمني لمتغير إرجاع الخطأ النهائي: $err . إنه أفضل من try() IMO. :-)

تضمين التغريدة

_ "شخصيًا ، أحب معالجة رمز الخطأ بعيدًا عن الطريق (في النهاية)" _

+1 لذلك!

أجد أن معالجة الأخطاء التي تم تنفيذها _ قبل_ حدوث الخطأ أصعب بكثير من التفكير فيها من معالجة الأخطاء المطبقة _ بعد_ حدوث الخطأ. إن الاضطرار إلى القفز عقليًا والقوة لمتابعة التدفق المنطقي يبدو وكأنني عدت في عام 1980 إلى كتابة Basic with GOTOs.

دعني أقترح طريقة أخرى محتملة لمعالجة الأخطاء باستخدام CopyFile() كمثال مرة أخرى:

func CopyFile(src, dst string) (err error) {

    r := os.Open(src)
    defer r.Close()

    w := os.Create(dst)
    defer w.Close()

    io.Copy(w, r)
    w.Close()

    for err := error {
        switch err.Source() {
        case w.Close:
            os.Remove(dst) // only if a “try” fails
            fallthrough
        case os.Open, os.Create, io.Copy:
            err = fmt.Errorf("copy %s %s: %v", src, dst, err)
        default:
            err = fmt.Errorf("an unexpected error occurred")
        }
    }

    return err
}

التغييرات اللغوية المطلوبة ستكون:

1. السماح بتركيب for error{} مشابه لـ for range{} لكن تم إدخاله فقط عند حدوث خطأ ولم يتم تنفيذه إلا مرة واحدة.

2. اسمح بحذف التقاط قيم الإرجاع التي تنفذ <object>.Error() string ولكن فقط عندما يوجد بناء for error{} داخل نفس func .

3. تسبب في تدفق التحكم في البرنامج للانتقال إلى السطر الأول من المكون for error{} عندما يُرجع func _ "خطأ" _ في قيمة الإرجاع الأخيرة.

4. عند إرجاع خطأ _ "خطأ" _ يضيف Go تعيين مرجع إلى func الذي أعاد الخطأ الذي يجب استرجاعه بواسطة <error>.Source()

ما هو _ "خطأ" _؟

حاليًا _ "خطأ" _ يتم تعريفه على أنه أي كائن يقوم بتنفيذ Error() string وبالطبع ليس nil .

ومع ذلك ، غالبًا ما تكون هناك حاجة لتوسيع الخطأ _ حتى عند النجاح_ للسماح بإرجاع القيم المطلوبة لنتائج نجاح واجهة برمجة تطبيقات RESTful. لذا أود أن أطلب من فريق Go ألا يفترض تلقائيًا أن err!=nil يعني _ "خطأ" _ ولكن بدلاً من ذلك تحقق مما إذا كان كائن خطأ ينفذ IsError() وإذا كان IsError() يعيد true قبل افتراض أن أي قيمة بخلاف nil هي _ "خطأ" _

_ (أنا لا أتحدث بالضرورة عن الكود في المكتبة القياسية ولكن بشكل أساسي إذا اخترت تدفق التحكم الخاص بك إلى الفرع على _ "خطأ" _. إذا نظرت فقط إلى err!=nil ، فسنكون محدودًا جدًا فيما نحن يمكن القيام به من حيث قيم الإرجاع في وظائفنا.) _

راجع للشغل ، السماح للجميع باختبار _ "خطأ" _ بالطريقة نفسها على الأرجح يمكن تنفيذها بسهولة عن طريق إضافة وظيفة جديدة مضمنة iserror() :

type ErrorIser interface {
    IsError() bool
}
func iserror(err error) bool {
    if err == nil { 
        return false
    }
    if _,ok := err.(ErrorIser); !ok {
        return true
    }
    return err.IsError()
}

فوائد جانبية للسماح بعدم التقاط _ "الأخطاء" _

لاحظ أن السماح بعدم التقاط آخر _ "خطأ" _ من مكالمات func سيسمح بإعادة البناء في وقت لاحق لإرجاع أخطاء من func s التي لم تكن بحاجة في البداية إلى إرجاع الأخطاء. وسيسمح بإعادة البناء هذه دون كسر أي كود موجود يستخدم هذا النوع من استعادة الأخطاء والمكالمات تقول func s.

بالنسبة لي ، فإن قرار _ "هل يجب أن أعيد خطأ أم أتخلى عن معالجة الخطأ للاتصال بالبساطة؟" _ هو أحد أكبر المآزق التي أواجهها عند كتابة كود Go. إن السماح بعدم التقاط _ "الأخطاء" _ أعلاه من شأنه أن يقضي على هذا المأزق.

لقد حاولت بالفعل تنفيذ هذه الفكرة بصفتي مترجم Go منذ حوالي نصف عام. ليس لدي رأي قوي حول ما إذا كان يجب إضافة هذه الميزة كـ Go المدمج ، ولكن دعني أشارك التجربة (على الرغم من أنني لست متأكدًا من أنها مفيدة).

https://github.com/rhysd/trygo

اتصلت بلغة TryGo الموسعة وطبقت مترجم TryGo to Go.

مع المترجم الشفرة

func CreateFileInSubdir(subdir, filename string, content []byte) error {
    cwd := try(os.Getwd())

    try(os.Mkdir(filepath.Join(cwd, subdir)))

    p := filepath.Join(cwd, subdir, filename)
    f := try(os.Create(p))
    defer f.Close()

    try(f.Write(content))

    fmt.Println("Created:", p)
    return nil
}

يمكن ترجمتها إلى

func CreateFileInSubdir(subdir, filename string, content []byte) error {
    cwd, _err0 := os.Getwd()
    if _err0 != nil {
        return _err0
    }

    if _err1 := os.Mkdir(filepath.Join(cwd, subdir)); _err1 != nil {
        return _err1
    }

    p := filepath.Join(cwd, subdir, filename)
    f, _err2 := os.Create(p)
    if _err2 != nil {
        return _err2
    }
    defer f.Close()

    if _, _err3 := f.Write(content); _err3 != nil {
        return _err3
    }

    fmt.Println("Created:", p)
    return nil
}

لتقييد اللغة ، لم أتمكن من تنفيذ try() call العام. يقتصر على

• RHS لبيان التعريف
• RHS بيان التخصيص
• بيان المكالمة

لكن يمكنني تجربة ذلك من خلال مشروعي الصغير. كانت تجربتي

• إنه يعمل بشكل جيد ويحفظ عدة أسطر
• قيمة الإرجاع المسماة غير قابلة للاستخدام بالفعل لـ err حيث يتم تحديد قيمة إرجاع وظيفتها بواسطة كل من التعيين والدالة الخاصة try() . محير جدا
• تفتقر هذه الوظيفة try() إلى ميزة "خطأ الالتفاف" كما تمت مناقشته أعلاه.

_ "كلاهما يبدو وكأنهما نتائج جيدة بالنسبة لي." _

سيتعين علينا أن نتفق على الاختلاف هنا.

_ "بناء الجملة هذا (ليس من الضروري) التعامل مع كل حالة استخدام" _

ربما يكون هذا الميم هو الأكثر إثارة للقلق. على الأقل بالنظر إلى مدى مقاومة فريق / مجتمع Go لأي تغييرات في الماضي لم تكن قابلة للتطبيق على نطاق واسع.

إذا سمحنا بهذا التبرير هنا ، فلماذا لا يمكننا إعادة النظر في المقترحات السابقة التي تم رفضها لأنها لم تكن قابلة للتطبيق على نطاق واسع؟

وهل نحن الآن منفتحون للدفاع عن التغييرات في Go التي تفيد فقط في حالات الحافة المحددة؟

في تخميني ، لن يؤدي وضع هذه السابقة إلى نتائج جيدة على المدى الطويل ...

_ "@ mikeshenkel" _

ملاحظة: لم أر رسالتك في البداية بسبب خطأ إملائي. _ (هذا لا يزعجني ، لا يتم إخطاري عند وجود أخطاء إملائية في اسم المستخدم الخاص بي ...) _

أقدر الالتزام بالتوافق مع الإصدارات السابقة الذي يحفزك على جعل try مدمجًا ، بدلاً من كلمة رئيسية ، ولكن بعد المصارعة مع الغرابة المطلقة لامتلاك وظيفة مستخدمة بشكل متكرر يمكنها تغيير تدفق التحكم ( panic و recover نادران للغاية) ، تساءلت: هل أجرى أي شخص أي تحليل واسع النطاق لتكرار try كمعرف في قواعد البرمجة مفتوحة المصدر؟ كنت فضوليًا ومتشككًا ، لذلك أجريت بحثًا أوليًا عبر ما يلي:

• https://github.com/google/go-github
• https://github.com/cockroachdb/cockroach
• https://github.com/golang/net
• https://github.com/exercism/xgo
• https://github.com/GoogleCloudPlatform/kubernetes
• https://github.com/syncthing/syncthing
• https://github.com/mitchellh/packer
• https://github.com/drone/drone
• https://github.com/coreos/etcd
• https://github.com/docker/docker
• https://github.com/sjwhitworth/golearn
• https://github.com/bitly/nsq
• https://github.com/smartystreets/goconvey
• https://github.com/golang/tools
• https://github.com/coreos/fleet
• https://github.com/limetext/lime
• https://github.com/flynn/flynn
• https://github.com/dropbox/godropbox
• https://github.com/hashicorp/consul
• https://github.com/hashicorp/terraform

عبر 11،108،770 سطرًا مهمًا من Go live في هذه المستودعات ، كان هناك 63 مثيلًا فقط من try يتم استخدامه كمعرف. بالطبع ، أدرك أن قواعد الرموز هذه (على الرغم من كونها كبيرة ، ومستخدمة على نطاق واسع ، ومهمة في حد ذاتها) لا تمثل سوى جزء بسيط من كود Go الموجود هناك ، بالإضافة إلى أنه ليس لدينا طريقة لتحليل قواعد الرموز الخاصة بشكل مباشر ، لكنها بالتأكيد نتيجة مثيرة للاهتمام.

علاوة على ذلك ، نظرًا لأن try ، مثل أي كلمة رئيسية ، هو أحرف صغيرة ، فلن تجده أبدًا في واجهة برمجة التطبيقات العامة للحزمة. ستؤثر إضافات الكلمات الرئيسية على العناصر الداخلية للحزمة فقط.

هذا كله مقدمة لبعض الأفكار التي أردت طرحها في المزيج الذي سيستفيد من try ككلمة رئيسية.

سأقترح الإنشاءات التالية.

1) لا معالج

// The existing proposal, but as a keyword rather than builtin.  When an error is 
// "caught", the function returns all zero values plus the error.  Nothing 
// particularly new here.
func doSomething() (int, error) {
    try SomeFunc()
    a, b := try AnotherFunc()

    // ...

    return 123, nil
}

2) معالج

لاحظ أن معالجات الأخطاء عبارة عن كتل تعليمات برمجية بسيطة ، يُقصد بها أن تكون مضمنة ، وليست وظائف. المزيد عن هذا أدناه.

func doSomething() (int, error) {
    // Inline error handler
    a, b := try SomeFunc() else err {
        return 0, errors.Wrap(err, "error in doSomething:")
    }

    // Named error handlers
    handler logAndContinue err {
        log.Errorf("non-critical error: %v", err)
    }
    handler annotateAndReturn err {
        return 0, errors.Wrap(err, "error in doSomething:")
    }

    c, d := try SomeFunc() else logAndContinue
    e, f := try OtherFunc() else annotateAndReturn

    // ...

    return 123, nil
}

القيود المقترحة:

• يمكنك فقط try استدعاء دالة. لا try err .
• إذا لم تحدد معالجًا ، فيمكنك فقط try من داخل دالة تقوم بإرجاع خطأ كقيمة إرجاع في أقصى اليمين. لا يوجد تغيير في كيفية تصرف try بناءً على سياقه. إنه لا يصيب بالذعر أبدًا (كما نوقش سابقًا في الموضوع).
• لا توجد "سلسلة معالج" من أي نوع. المعالجات هي مجرد كتل تعليمات برمجية غير قابلة للإدخال.

فوائد:

• يمكن فصل بناء الجملة try / else بشكل بسيط في "المركب" الحالي إذا:
  go a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "error in doSomething:") }
  يصبح
  go if a, b, err := SomeFunc(); err != nil { return 0, errors.Wrap(err, "error in doSomething:") }
  بالنسبة لعيني ، بدت ifs المركبة دائمًا مربكة أكثر من كونها مفيدة لسبب بسيط للغاية: تحدث الحالات الشرطية عمومًا بعد العملية الجراحية ، ولها علاقة بمعالجة نتائجها. إذا كانت العملية محصورة داخل العبارة الشرطية ، فمن غير الواضح أنها تحدث. العين مشتتة. علاوة على ذلك ، فإن نطاق المتغيرات المحددة ليس واضحًا على الفور كما هو الحال عندما يتم تركها على الخط.
• لا يتم تعريف معالجات الأخطاء عن قصد على أنها وظائف (ولا مع أي شيء يشبه الدلالات الشبيهة بالوظيفة). هذا يفعل العديد من الأشياء بالنسبة لنا:
  
  
  
  • يمكن للمترجم ببساطة تضمين معالج مسمى أينما تمت الإشارة إليه. إنه يشبه إلى حد كبير قالب ماكرو / ترميز بسيط من استدعاء دالة. لا يحتاج وقت التشغيل حتى إلى معرفة وجود المعالجات.
  
  
  • نحن لسنا مقيدين فيما يتعلق بما يمكننا القيام به داخل المعالج. نتفادى النقد الموجه إلى check / handle بأن "إطار معالجة الخطأ هذا مفيد فقط لعمليات الإنقاذ". نتغلب أيضًا على انتقادات "سلسلة المعالج". يمكن وضع أي رمز تعسفي داخل أحد هذه المعالجات ، ولا يتم تضمين أي تدفق تحكم آخر.
  
  
  • لا يتعين علينا اختطاف return داخل المعالج لتعني super return . اختطاف كلمة رئيسية أمر محير للغاية. return يعني فقط return ، وليس هناك حاجة حقيقية لـ super return .
  
  
  • لا يحتاج defer إلى ضوء القمر كآلية لمعالجة الأخطاء. يمكننا الاستمرار في التفكير في الأمر بشكل أساسي باعتباره وسيلة لتنظيف الموارد ، وما إلى ذلك.
  
  
• فيما يتعلق بإضافة السياق إلى الأخطاء:
  
  
  
  • تعد إضافة السياق باستخدام المعالجات أمرًا بسيطًا للغاية ويبدو مشابهًا جدًا لمجموعات if err != nil الموجودة
  
  
  • على الرغم من أن بنية "المحاولة بدون المعالج" لا تشجع بشكل مباشر على إضافة سياق ، إلا أنه من السهل جدًا إعادة البناء في نموذج المعالج. سيكون الاستخدام المقصود في المقام الأول أثناء التطوير ، وسيكون من السهل جدًا كتابة شيك go vet لتسليط الضوء على الأخطاء التي لم تتم معالجتها.
  
  

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

brynbellomy شكرًا على تحليل الكلمات الرئيسية - هذه معلومات مفيدة جدًا. يبدو أن try ككلمة رئيسية قد تكون جيدة. (أنت تقول إن واجهات برمجة التطبيقات (API) لم تتأثر - هذا صحيح ، ولكن قد يستمر ظهور try كاسم معلمة أو ما شابه - لذلك قد يتعين تغيير الوثائق. لكنني أوافق على أن ذلك لن يؤثر على عملاء هذه الحزم.)

فيما يتعلق باقتراحك: سيكون الأمر جيدًا حتى بدون معالجات محددة ، أليس كذلك؟ (هذا من شأنه أن يبسط الاقتراح دون فقدان القوة. يمكن للمرء ببساطة استدعاء دالة محلية من المعالج المضمن.)

فيما يتعلق باقتراحك: سيكون الأمر جيدًا حتى بدون معالجات محددة ، أليس كذلك؟ (هذا من شأنه أن يبسط الاقتراح دون فقدان القوة. يمكن للمرء ببساطة استدعاء دالة محلية من المعالج المضمن.)

griesemer في الواقع - كنت أشعر بالفتور الشديد بشأن تضمين هؤلاء. بالتأكيد المزيد من Go-ish بدون.

من ناحية أخرى ، يبدو أن الناس يريدون القدرة على معالجة الأخطاء أحادية الخطوط ، بما في ذلك الخطوط المفردة التي return . ستكون الحالة النموذجية هي السجل ، ثم return . إذا استخدمنا دالة محلية في عبارة else ، فربما نفقد ما يلي:

a, b := try SomeFunc() else err {
    someLocalFunc(err)
    return 0, err
}

(ما زلت أفضل هذا على ifs المركب ، رغم ذلك)

ومع ذلك ، لا يزال بإمكانك الحصول على مرتجعات ذات سطر واحد تضيف سياق خطأ من خلال تنفيذ قرص بسيط gofmt تمت مناقشته مسبقًا في السلسلة:

a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

هل الكلمة الرئيسية الجديدة ضرورية في الاقتراح أعلاه؟ لما لا:

SomeFunc() else return
a, b := SomeOtherFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

griesemer إذا عادت المعالجات إلى الطاولة ، أقترح عليك إصدار عدد جديد لمناقشة try / handle أو try / _label_. حذف هذا الاقتراح المعالجات على وجه التحديد ، وهناك طرق لا حصر لها لتعريفهم واستدعاءهم.

يجب على أي شخص يقترح معالجات قراءة ويكي التغذية المرتدة الخاصة بالتحقق / التعامل أولاً. من الجيد أن كل ما تحلم به موصوف بالفعل هناك :-)
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback

smonkewitz لا ، كلمة رئيسية جديدة ليست ضرورية في هذا الإصدار لأنها مرتبطة ببيانات التخصيص ، والتي تم ذكرها عدة مرات حتى الآن في العديد من بناء الجملة sugar.

https://github.com/golang/go/issues/32437#issuecomment -499808741
https://github.com/golang/go/issues/32437#issuecomment -499852124
https://github.com/golang/go/issues/32437#issuecomment -500095505

ianlancetaylor هل هذه النكهة الخاصة للتعامل مع الأخطاء قد نظر فيها فريق go حتى الآن؟ ليس من السهل تنفيذ المحاولة المقترحة ولكنها تبدو أكثر اصطلاحية. ~ بيان لا داعي له ، آسف. ~

أود أن أكرر شيئًا ما قالهdeanveloper وقليل من الآخرين ، ولكن بتركيزي الخاص. في https://github.com/golang/go/issues/32437#issuecomment -498939499deanveloper قال:

try هو إرجاع مشروط. يتم تعليق كل من تدفق التحكم والعودة على قواعد في Go. يتم وضع مسافة بادئة لكل تدفق التحكم داخل دالة ، وتبدأ جميع المرتجعات بـ return . إن المزج بين هذين المفهومين معًا في استدعاء دالة سهل الفقدان يبدو قليلاً.

علاوة على ذلك ، في هذا الاقتراح ، try دالة تقوم بإرجاع قيم ، لذلك يمكن استخدامها كجزء من تعبير أكبر.

جادل البعض بأن panic قد حدد بالفعل سابقة لوظيفة مضمنة تغير تدفق التحكم ، لكنني أعتقد أن panic يختلف اختلافًا جوهريًا لسببين:

1. الذعر ليس مشروطا. دائما يجهض وظيفة الاستدعاء.
2. لا يُرجع الذعر أي قيم وبالتالي يمكن أن يظهر فقط كإفادة قائمة بذاتها ، مما يزيد من وضوحها.

جرب من ناحية أخرى:

1. مشروط قد يعود أو لا يعود من وظيفة الاستدعاء.
2. تُرجع القيم ويمكن أن تظهر في تعبير مركب ، ربما عدة مرات ، على سطر واحد ، وربما يتجاوز الهامش الأيمن لنافذة المحرر.

لهذه الأسباب أعتقد أن try يبدو أكثر من مجرد "قليل من الراحة" ، أعتقد أنه يضر بشكل أساسي بقراءة الكود.

اليوم ، عندما نواجه بعض أكواد Go للمرة الأولى ، يمكننا تخطيها سريعًا للعثور على نقاط الخروج المحتملة ونقاط التدفق للتحكم. أعتقد أن هذه خاصية ذات قيمة عالية لـ Go Code. باستخدام try يصبح من السهل جدًا كتابة كود لا يحتوي على هذه الخاصية.

أعترف أنه من المحتمل أن تتقارب قابلية قراءة كود القيمة من مطوري Go مع مصطلحات الاستخدام مقابل try لتجنب مخاطر قابلية القراءة هذه. آمل أن يحدث هذا لأن قابلية قراءة الكود تبدو قيمة أساسية للعديد من مطوري Go. لكن ليس من الواضح بالنسبة لي أن try يضيف قيمة كافية على مصطلحات الكود الحالية لتحمل ثقل إضافة مفهوم جديد إلى اللغة ليتعلمه الجميع ويمكن أن يضر ذلك بسهولة بالقراءة.

""
إذا! = "معطلة" {
dontFix (ذلك)
}

ChrisHines بالنسبة إلى وجهة نظرك (والتي ترد صدى في مكان آخر في هذا الموضوع) ، دعنا نضيف قيدًا آخر:

• أي عبارة try (حتى تلك التي لا تحتوي على معالج) يجب أن تحدث في سطر خاص بها.

ستظل تستفيد من انخفاض كبير في الضوضاء المرئية. بعد ذلك ، تكون قد ضمنت المرتجعات التي تم التعليق عليها بواسطة return والعوائد المشروطة التي تم التعليق عليها بواسطة try ، وتقف هذه الكلمات الرئيسية دائمًا في بداية السطر (أو في أسوأ الأحوال ، مباشرة بعد تعيين متغير).

لذلك ، لا شيء من هذا النوع من الهراء:

try EmitEvent(try (try DecodeMsg(m)).SaveToDB())

بل بالأحرى هذا:

dm := try DecodeMsg(m)
um := try dm.SaveToDB()
try EmitEvent(um)

الذي لا يزال يبدو أوضح من هذا:

dm, err := DecodeMsg(m)
if err != nil {
    return nil, err
}

um, err := dm.SaveToDB()
if err != nil {
    return nil, err
}

err = EmitEvent(um)
if err != nil {
    return nil, err
}

أحد الأشياء التي أحبه في هذا التصميم هو أنه من المستحيل تجاهل الأخطاء بصمت دون الاستمرار في التعليق على احتمال حدوثها . بينما ترى الآن أحيانًا x, _ := SomeFunc() (ما هي قيمة الإرجاع التي تم تجاهلها؟ خطأ؟ شيء آخر؟) ، الآن عليك أن تشرح بوضوح:

x := try SomeFunc() else err {}

منذ رسالتي السابقة لدعم الاقتراح ، رأيت فكرتين تم نشرهما بواسطة jagv (بدون معلمات try تُرجع *error ) وبواسطة josharian (معالجات الأخطاء المسمى) والتي أؤمن بها شكل معدّل بشكل طفيف من شأنه أن يعزز الاقتراح إلى حد كبير.

من خلال وضع هذه الأفكار جنبًا إلى جنب مع فكرة أخرى لدي ، سيكون لدينا أربعة إصدارات من try :

1. يحاول()
2. محاولة (بارامز)
3. محاولة (بارامس ، تسمية)
4. محاولة (بارامز ، ذعر)

1 سيعيد ببساطة مؤشرًا إلى معامل إرجاع الخطأ (ERP) أو لا شيء إذا لم يكن هناك واحد (# 4 فقط). هذا من شأنه أن يوفر بديلاً لتخطيط موارد المؤسسات اسمه دون الحاجة إلى إضافة المزيد من الدعم.

2 سيعمل تمامًا كما هو متصور حاليًا. سيتم إرجاع الخطأ غير الصفري على الفور ولكن يمكن تزيينه بعبارة defer .

3 سيعمل على النحو الذي اقترحه josharian ، على سبيل المثال ، في حالة الخطأ غير الصفري ، سوف يتفرع الكود إلى الملصق. ومع ذلك ، لن يكون هناك تسمية افتراضية لمعالج الأخطاء لأن هذه الحالة ستتدهور الآن إلى رقم 2.

يبدو لي أن هذا سيكون عادةً طريقة أفضل لتزيين الأخطاء (أو التعامل معها محليًا ثم إعادة لا شيء) من defer لأنه أبسط وأسرع. أي شخص لم يعجبه لا يزال بإمكانه استخدام # 2.

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

لذا فإن التسمية العادية والسلوك goto سيطبقان الموضوع (كما قال josharian ) على # 26058 الذي يتم إصلاحه أولاً ولكن أعتقد أنه يجب إصلاحه على أي حال.

لا يمكن أن يكون اسم التصنيف panic لأن هذا قد يتعارض مع رقم 4.

4 سيكون panic على الفور بدلاً من العودة أو التفريع. وبالتالي ، إذا كان هذا هو الإصدار الوحيد من try المستخدم في وظيفة معينة ، فلن تكون هناك حاجة لتخطيط موارد المؤسسات.

لقد أضفت هذا حتى يمكن أن تعمل حزمة الاختبار كما هي الآن دون الحاجة إلى مزيد من التغييرات المضمنة أو غيرها من التغييرات. ومع ذلك ، قد يكون مفيدًا في السيناريوهات "المميتة" الأخرى أيضًا.

يجب أن يكون هذا إصدارًا منفصلاً من try كبديل للتفرع إلى معالج الأخطاء ، ثم الفزع من ذلك لا يزال يتطلب تخطيط موارد المؤسسات (ERP).

كان أحد أقوى أنواع ردود الفعل على الاقتراح الأولي هو القلق بشأن فقدان الرؤية السهلة للتدفق الطبيعي لمكان عودة الوظيفة.

على سبيل المثال ، أعرب deanveloper عن هذا القلق جيدًا في https://github.com/golang/go/issues/32437#issuecomment -498932961 ، والذي أعتقد أنه أعلى تعليق تم التصويت عليه هنا.

dominikh كتب في https://github.com/golang/go/issues/32437#issuecomment -499067357:

في التعليمات البرمجية gofmt'ed ، يطابق العائد دائمًا / ^ \ t * return / - إنه نمط تافه جدًا يمكن ملاحظته بالعين ، دون أي مساعدة. المحاولة ، من ناحية أخرى ، يمكن أن تحدث في أي مكان في الكود ، متداخلة بشكل تعسفي بعمق في استدعاءات الوظائف. لن يجعلنا أي قدر من التدريب قادرين على تحديد كل تدفق التحكم على الفور في وظيفة بدون مساعدة الأداة.

للمساعدة في ذلك ، اقترح brynbellomy بالأمس:

يجب أن تحدث أي عبارة try (حتى تلك التي لا تحتوي على معالج) في سطر خاص بها.

مع أخذ ذلك أبعد من ذلك ، قد يكون مطلوبًا أن يكون try بداية السطر ، حتى بالنسبة للمهمة.

لذلك يمكن أن يكون:

try dm := DecodeMsg(m)
try um := dm.SaveToDB()
try EmitEvent(um)

بدلاً من التالي (من مثالbrynbellomy ):

dm, err := DecodeMsg(m)
if err != nil {
    return nil, err
}

um, err := dm.SaveToDB()
if err != nil {
    return nil, err
}

err = EmitEvent(um)
if err != nil {
    return nil, err
}

يبدو أن هذا سيحافظ على قدر معقول من الرؤية ، حتى بدون أي محرر أو مساعدة IDE ، مع تقليل النموذج المعياري.

يمكن أن يعمل ذلك مع النهج القائم على التأجيل المقترح حاليًا والذي يعتمد على معلمات النتائج المسماة ، أو يمكن أن يعمل مع تحديد وظائف المعالج العادية. (يبدو أن تحديد وظائف المعالج دون طلب قيم إرجاع مسماة أفضل من طلب قيم إرجاع مسماة ، لكن هذه نقطة منفصلة).

يتضمن الاقتراح هذا المثال:

info := try(try(os.Open(file)).Stat())    // proposed try built-in

يمكن أن يكون ذلك بدلاً من ذلك:

try f := os.Open(file)
try info := f.Stat()

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

قدم @ elagergren-spideroak هذا المثال:

try(try(try(to()).parse().this)).easily())

أعتقد أن هذا يحتوي على أقواس غير متطابقة ، والتي ربما تكون نقطة مقصودة أو نوعًا من الفكاهة ، لذلك لست متأكدًا مما إذا كان هذا المثال ينوي الحصول على 2 try أو 3 try . على أي حال ، ربما يكون من الأفضل طلب نشر ذلك عبر 2-3 أسطر تبدأ بـ try .

thepudds ، هذا ما كنت أفهمه في تعليقي السابق. ماعدا ذلك المعطى

try f := os.Open(file)
try info := f.Stat()

الشيء الواضح الذي يجب فعله هو التفكير في try على أنه كتلة تجريبية حيث يمكن وضع أكثر من جملة واحدة بين قوسين. لذلك يمكن أن يصبح ما سبق

try (
    f := os.Open(file)
    into := f.Stat()
)

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

try info := os.Open(file).Stat()

من تواقيع الوظيفة ، يعرف المترجم أن Open يمكنه إرجاع قيمة خطأ وكما هو الحال في كتلة try ، فإنه يحتاج إلى إنشاء معالجة للأخطاء ثم استدعاء Stat () على القيمة الأولية المرتجعة وما إلى ذلك.

الشيء التالي هو السماح للعبارات التي لا يتم فيها إنشاء قيمة خطأ أو التعامل معها محليًا. لذلك يمكنك القول الآن

try (
    f := os.Open(file)
    debug("f: %v\n", f) // debug returns nothing
    into := f.Stat()
)

هذا يسمح بتطوير التعليمات البرمجية دون الحاجة إلى إعادة ترتيب كتل المحاولة. ولكن لسبب غريب يبدو أن الناس يعتقدون أن معالجة الأخطاء يجب أن يتم توضيحها صراحة! هم يريدون

try(try(try(to()).parse()).this)).easily())

بينما أنا بخير تمامًا مع

try to().parse().this().easily()

على الرغم من أنه في كلتا الحالتين يمكن إنشاء نفس رمز التحقق من الأخطاء بالضبط. وجهة نظري هي أنه يمكنك دائمًا كتابة رمز خاص لمعالجة الأخطاء إذا كنت بحاجة إلى ذلك. يقوم try (أو أيًا كان ما تفضل تسميته) ببساطة بإلغاء معالجة الأخطاء الافتراضية (وهو دفعها للمتصل).

فائدة أخرى هي أنه إذا قام المترجم بإنشاء معالجة الأخطاء الافتراضية ، فيمكنه إضافة المزيد من معلومات التعريف حتى تعرف أي من الوظائف الأربعة المذكورة أعلاه فشلت.

كنت قلقًا إلى حد ما بشأن قابلية قراءة البرامج حيث يظهر try داخل تعبيرات أخرى. لذلك قمت بتشغيل grep "return .*err$" على المكتبة القياسية وبدأت في قراءة الكتل بشكل عشوائي. هناك 7214 نتيجة ، قرأت بضع مئات فقط.

أول شيء يجب ملاحظته هو أنه عند تطبيق try ، فإنه يجعل كل هذه الكتل تقريبًا أكثر قابلية للقراءة.

الأمر الثاني هو أن عددًا قليلاً جدًا من هؤلاء ، أقل من 1 من كل 10 ، سيضع try داخل تعبير آخر. الحالة النموذجية هي كشوف الحساب بالصيغة x := try(...) أو ^try(...)$ .

فيما يلي بعض الأمثلة حيث يظهر try داخل تعبير آخر:

نص / نموذج

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        lessOrEqual, err := le(arg1, arg2)
        if err != nil {
                return false, err
        }
        return !lessOrEqual, nil
}

يصبح:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        return !try(le(arg1, arg2)), nil
}

نص / نموذج

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
...
        switch v.Kind() {
        case reflect.Map:
                index, err := prepareArg(index, v.Type().Key())
                if err != nil {
                        return reflect.Value{}, err
                }
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

يصبح

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                if x := v.MapIndex(try(prepareArg(index, v.Type().Key()))); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

(هذا هو المثال الأكثر إثارة للتساؤل الذي رأيته)

regexp / بناء الجملة:

regexp/syntax/parse.go

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        if c, t, err = nextRune(t); err != nil {
                return nil, err
        }
        p.literal(c)
        ...
}

يصبح

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        c, t = try(nextRune(t))
        p.literal(c)
        ...
}

هذا ليس مثالاً على المحاولة داخل تعبير آخر ولكني أريد تسميته لأنه يحسن إمكانية القراءة. من الأسهل كثيرًا أن ترى هنا أن قيم c و t تعيش خارج نطاق عبارة if.

صافي / http

net / http / request.go: readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

يصبح:

        req.Header = Header(try(tp.ReadMIMEHeader())

قاعدة البيانات / SQL

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

يصبح

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

قاعدة البيانات / SQL

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

يصبح

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }

صافي / http

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                cc, err := p.t.dialclientconn(addr, singleuse)
                if err != nil {
                        return nil, err
                }
                return cc, nil
        }

يصبح

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                return try(p.t.dialclientconn(addr, singleuse))
        }

صافي / http

func (f *http2Framer) endWrite() error {
        ...
        n, err := f.w.Write(f.wbuf)
        if err == nil && n != len(f.wbuf) {
                err = io.ErrShortWrite
        }
        return err
}

يصبح

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

(هذا الذي أحبه حقًا.)

صافي / http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

يصبح

        hc = try(fr.ReadFrame()).(*http2ContinuationFrame)// guaranteed by checkFrameOrder

}

(أيضا لطيفة.)

صافي :

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

يصبح

        if ctrlFn != nil {
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), try(newRawConn(fd))))
        }

ربما يكون هذا كثيرًا ، وبدلاً من ذلك يجب أن يكون:

        if ctrlFn != nil {
                c := try(newRawConn(fd))
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), c))
        }

بشكل عام ، أستمتع تمامًا بتأثير try على كود المكتبة القياسي الذي قرأته.

نقطة أخيرة: رؤية تطبيق try لقراءة التعليمات البرمجية بخلاف الأمثلة القليلة في الاقتراح كان مفيدًا. أعتقد أنه من المفيد التفكير في كتابة أداة لتحويل الكود تلقائيًا لاستخدام try (حيث لا يغير ذلك من دلالات البرنامج). سيكون من المثير للاهتمام قراءة عينة من الاختلافات التي يتم إنتاجها مقابل الحزم الشائعة على جيثب لمعرفة ما إذا كان ما وجدته في المكتبة القياسية ثابتًا. يمكن لمخرجات مثل هذا البرنامج أن توفر نظرة ثاقبة إضافية حول تأثير الاقتراح.

شكرًا crawshaw على القيام بذلك ، كان من الرائع رؤيته أثناء العمل. لكن رؤيتي له أثناء العمل جعلني آخذ الحجج ضد معالجة الخطأ المضمّن بجدية أكبر والتي كنت أرفضها حتى الآن.

نظرًا لأن هذا كان قريبًا جدًا من اقتراح thepudds المثير للاهتمام بجعل العبارة try ، أعدت كتابة جميع الأمثلة باستخدام بناء الجملة هذا ووجدته أكثر وضوحًا من التعبير- try أو الوضع الراهن ، دون الحاجة إلى عدد كبير جدًا من الأسطر الإضافية:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                try index := prepareArg(index, v.Type().Key())
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        try c, t = nextRune(t)
        p.literal(c)
        ...
}

        try mimeHeader := tp.ReadMIMEHeader()
        req.Header = Header(mimeHeader)

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                try connector := driverCtx.OpenConnector(dataSourceName)
                return OpenDB(connector), nil
        }

يمكن القول إن هذا أفضل مع تعبير- try إذا كان هناك عدة حقول يجب أن تكون try -ed ، لكنني ما زلت أفضل رصيد هذه المقايضة

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

هذا في الأساس هو أسوأ حالة لهذا ويبدو أنه جيد:

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                try cc := p.t.dialclientconn(addr, singleuse)
                return cc, nil
        }

لقد ناقشت مع نفسي ما إذا كان if try سيكون قانونيًا أو يجب أن يكون قانونيًا ، لكن لم أتمكن من التوصل إلى تفسير معقول لماذا لا يجب أن يكون ، وهو يعمل جيدًا هنا:

func (f *http2Framer) endWrite() error {
        ...
        if try n := f.w.Write(f.wbuf); n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

        try f := fr.ReadFrame()
        hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder

        if ctrlFn != nil {
                try c := newRawConn(fd)
                try ctrlFn(fd.ctrlNetwork(), laddr.String(), c)
        }

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

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

أيضًا ، try لا "يجرب" أي شيء. إنه "مرحل وقائي". إذا تم إيقاف تشغيل الدلالات الأساسية للاقتراح ، فأنا لست مندهشًا من أن الكود الناتج يمثل مشكلة أيضًا.

func (f *http2Framer) endWrite() error {
        ...
        relay n := f.w.Write(f.wbuf)
        return checkShortWrite(n, len(f.wbuf))
}

إذا قمت بتجربة عبارة ، يمكنك استخدام علامة للإشارة إلى القيمة المرجعة ، والإجراء:

try c, @      := newRawConn(fd) // return
try c, <strong i="6">@panic</strong> := newRawConn(fd) // panic
try c, <strong i="7">@hname</strong> := newRawConn(fd) // invoke named handler
try c, <strong i="8">@_</strong>     := newRawConn(fd) // ignore, or invoke "ignored" handler if defined

ما زلت بحاجة إلى بناء جملة تعبير فرعي (ذكر روس أنه مطلب) ، على الأقل من أجل الذعر وتجاهل الإجراءات.

أولاً ، أحيي crawshaw لأخذ الوقت الكافي للنظر في ما يقرب من 200 مثال حقيقي واستغراق الوقت في كتابته المدروسة أعلاه.

ثانيًا ، jimmyfrasche ، بخصوص إجابتك هنا حول مثال http2Framer :

لقد ناقشت مع نفسي ما إذا كان if try سيكون قانونيًا أو يجب أن يكون قانونيًا ، لكن لم أتمكن من التوصل إلى تفسير معقول لماذا لا يجب أن يكون ، وهو يعمل جيدًا هنا:

""
func (f * http2Framer) خطأ endWrite () {
...
إذا جرب n: = fwWrite (f.wbuf) ؛ n! = len (f.wbuf) {
إرجاع io.ErrShortWrite
}
العودة لا شيء
}

At least under what I was suggesting above in https://github.com/golang/go/issues/32437#issuecomment-500213884, under that proposal variation I would suggest `if try` is not allowed.

That `http2Framer` example could instead be:

func (f * http2Framer) خطأ endWrite () {
...
جرب ن: = fwWrite (f.wbuf)
إذا كان n! = len (f.wbuf) {
إرجاع io.ErrShortWrite
}
العودة لا شيء
}
`` That is one line longer, but hopefully still "light on the page". Personally, I think that (arguably) reads more cleanly, but more importantly it is easier to see the try`.

كتب Deanveloper أعلاه في https://github.com/golang/go/issues/32437#issuecomment -498932961:

يبدو أن العودة من وظيفة كانت شيئًا "مقدسًا" يجب القيام به

انتهى هذا المثال http2Framer المحدد ليس قصيرًا كما يمكن أن يكون. ومع ذلك ، فإنه يحمل العودة من وظيفة أكثر "مقدسة" إذا كان يجب أن يكون try أول شيء في السطر.

crawshaw المذكورة:

الأمر الثاني هو أن عددًا قليلاً جدًا من هؤلاء ، أقل من 1 من كل 10 ، سيضع المحاولة داخل تعبير آخر. الحالة النموذجية هي عبارات بالصيغة x: = try (...) أو ^ try (...) $.

ربما يكون من المقبول مساعدة هؤلاء 1 من 10 أمثلة بشكل أكثر تقييدًا من try جزئيًا ، خاصة إذا كانت الحالة النموذجية من هذه الأمثلة تنتهي بنفس عدد السطور حتى لو كان try مطلوب ليكون أول شيء على الخط؟

تضمين التغريدة

شكرًا crawshaw على القيام بذلك ، كان من الرائع رؤيته أثناء العمل. لكن رؤيتي له أثناء العمل جعلني آخذ الحجج ضد معالجة الخطأ المضمّن بجدية أكبر والتي كنت أرفضها حتى الآن.

نظرًا لأن هذا كان قريبًا جدًا من اقتراح thepudds المثير للاهتمام بجعل العبارة try ، أعدت كتابة جميع الأمثلة باستخدام بناء الجملة هذا ووجدته أكثر وضوحًا من التعبير- try أو الوضع الراهن ، دون الحاجة إلى عدد كبير جدًا من الأسطر الإضافية:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

يوضح المثال الأول جيدًا سبب تفضيلي الشديد للتعبير- try . في نسختك ، يجب أن أضع نتيجة الاستدعاء على le في متغير ، لكن هذا المتغير ليس له معنى دلالي أن المصطلح le لا يعنيه بالفعل. لذلك لا يوجد اسم يمكنني إعطائه أنه ليس بلا معنى (مثل x ) أو زائداً عن الحاجة (مثل lessOrEqual ). مع التعبير- try ، لا حاجة إلى متغير وسيط ، لذلك لا تظهر هذه المشكلة.

أفضل ألا أبذل مجهودًا عقليًا لابتكار أسماء لأشياء من الأفضل تركها مجهولة.

يسعدني أن أقدم دعمي وراء المنشورات القليلة الماضية حيث تم نقل try (الكلمة الأساسية) إلى بداية السطر. يجب حقًا مشاركة نفس المساحة المرئية مثل return .

رد: اقتراحjimmyfrasche بالسماح بدولار try ضمن بيانات المركب if ، هذا هو بالضبط نوع الأشياء التي أعتقد أن الكثيرين هنا يحاولون تجنبها ، لعدة أسباب:

• إنه يدمج آليتين مختلفتين تمامًا لتدفق التحكم في سطر واحد
• يتم تقييم التعبير try أولاً ، ويمكن أن يتسبب في إرجاع الدالة ، ومع ذلك يظهر بعد if
• يعودون بأخطاء مختلفة تمامًا ، أحدها لا نراه بالفعل في الكود ، والآخر نفعله
• يجعل الأمر أقل وضوحًا أن try لم يتم التعامل معه بالفعل ، لأن الكتلة تشبه إلى حد كبير كتلة معالج (على الرغم من أنها تتعامل مع مشكلة مختلفة تمامًا)

يمكن للمرء أن يتعامل مع هذا الموقف من زاوية مختلفة قليلاً تفضل دفع الناس للتعامل مع try s. ماذا عن السماح لصيغة try / else بأن تحتوي على شروط لاحقة (وهو نمط شائع مع العديد من وظائف الإدخال / الإخراج التي تُرجع كلاً من err و n ، قد يشير أي منهما إلى وجود مشكلة):

func (f *http2Framer) endWrite() error {
        // ...
        try n := f.w.Write(f.wbuf) else err {
                return errors.Wrap(err, "error writing:")
        } else if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

في حالة عدم معالجة الخطأ الذي تم إرجاعه بمقدار .Write ، فلا يزال لديك تعليق توضيحي واضح بأن .Write قد يكون خطأ (كما أشارthepudds):

func (f *http2Framer) endWrite() error {
        // ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

أنا ثاني استجابة daved . في رأيي ، أصبح كل مثال تم تمييزهcrawshaw أقل وضوحًا وأكثر عرضة للخطأ كنتيجة لـ try .

يسعدني أن أقدم دعمي وراء المنشورات القليلة الماضية حيث تم نقل try (الكلمة الأساسية) إلى بداية السطر. يجب حقًا مشاركة نفس المساحة المرئية مثل return .

بالنظر إلى الخيارين لهذه النقطة وبافتراض أنه تم اختيار أحدهما ، وبالتالي تم تعيينه إلى حد ما سابقة للميزات المحتملة في المستقبل:

أ.)

try f := os.Open(filepath) else err {
    return errors.Wrap(err, "can't open")
}

ب.)

f := try os.Open(filepath) else err {
    return errors.Wrap(err, "can't open")
}

أي من الاثنين يوفر مزيدًا من المرونة لاستخدام الكلمات الرئيسية الجديدة في المستقبل؟ _ (لا أعرف الإجابة على هذا لأنني لم أتقن الفن المظلم لكتابة المترجمين.) _ هل سيكون أسلوب ما أكثر تقييدًا من الآخر؟

تضمين التغريدة
أنا أميل إلى الاتفاق مع Daves على هذا: في أمثلة crawshaw ، هناك الكثير من عبارات try مضمنة في أعماق سطور بها الكثير من الأشياء الأخرى. حقا من الصعب تحديد نقاط الخروج. علاوة على ذلك ، يبدو أن أقواس try تشوش الأشياء بشكل سيء في بعض الأمثلة.

إن رؤية مجموعة من التعليمات البرمجية stdlib التي تم تحويلها بهذا الشكل مفيدة للغاية ، لذلك أخذت نفس الأمثلة ولكن أعدت كتابتها وفقًا للاقتراح البديل ، وهو أكثر تقييدًا:

• try ككلمة رئيسية
• فقط try لكل سطر
• يجب أن يكون try في بداية السطر

نأمل أن يساعدنا هذا في المقارنة. أنا شخصياً أجد أن هذه الأمثلة تبدو أكثر إيجازًا من أصولها ، ولكن دون حجب تدفق التحكم. يظل try مرئيًا جدًا في أي مكان يتم استخدامه فيه.

نص / نموذج

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        lessOrEqual, err := le(arg1, arg2)
        if err != nil {
                return false, err
        }
        return !lessOrEqual, nil
}

يصبح:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

نص / نموذج

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
...
        switch v.Kind() {
        case reflect.Map:
                index, err := prepareArg(index, v.Type().Key())
                if err != nil {
                        return reflect.Value{}, err
                }
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

يصبح

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                try index := prepareArg(index, v.Type().Key())
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

regexp / بناء الجملة:

regexp/syntax/parse.go

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        if c, t, err = nextRune(t); err != nil {
                return nil, err
        }
        p.literal(c)
        ...
}

يصبح

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        try c, t = nextRune(t)
        p.literal(c)
        ...
}

صافي / http

net / http / request.go: readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

يصبح:

        try mimeHeader := tp.ReadMIMEHeader()
        req.Header = Header(mimeHeader)

قاعدة البيانات / SQL

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

يصبح

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                try connector := driverCtx.OpenConnector(dataSourceName)
                return OpenDB(connector), nil
        }

قاعدة البيانات / SQL

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

يصبح

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

صافي / http

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                cc, err := p.t.dialclientconn(addr, singleuse)
                if err != nil {
                        return nil, err
                }
                return cc, nil
        }

يصبح

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                try cc := p.t.dialclientconn(addr, singleuse)
                return cc, nil
        }

صافي / http
هذا لا يحفظنا في الواقع أي سطور ، لكنني أجده أكثر وضوحًا لأن if err == nil بناء غير مألوف نسبيًا.

func (f *http2Framer) endWrite() error {
        ...
        n, err := f.w.Write(f.wbuf)
        if err == nil && n != len(f.wbuf) {
                err = io.ErrShortWrite
        }
        return err
}

يصبح

func (f *http2Framer) endWrite() error {
        ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

صافي / http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

يصبح

        try f := fr.ReadFrame()
        hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
}

صافي:

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

يصبح

        if ctrlFn != nil {
                try c := newRawConn(fd)
                try ctrlFn(fd.ctrlNetwork(), laddr.String(), c)
        }

@ james-lawrence ردًا على https://github.com/golang/go/issues/32437#issuecomment -500116099: لا أتذكر أفكارًا مثل , err الاختياري الذي يتم النظر فيه بجدية ، لا. أنا شخصياً أعتقد أنها فكرة سيئة ، لأنها تعني أنه إذا تغيرت دالة لإضافة معلمة error لاحقة ، ستستمر الشفرة الحالية في التجميع ، ولكنها ستتصرف بشكل مختلف تمامًا.

استخدام التأجيل لمعالجة الأخطاء له معنى كبير ، لكنه يؤدي إلى الحاجة إلى تسمية الخطأ ونوع جديد من المتغيرات المتغيرة if err != nil .

تحتاج المعالجات الخارجية إلى القيام بذلك:

func handler(err *error) {
  if *err != nil {
    *err = handle(*err)
  }
} 

الذي يستخدم مثل

defer handler(&err)

يجب كتابة المعالجات الخارجية مرة واحدة فقط ولكن يجب أن يكون هناك نسختان من العديد من وظائف معالجة الأخطاء: الأولى التي يجب تأجيلها والأخرى التي سيتم استخدامها بالطريقة المعتادة.

تحتاج المعالجات الداخلية إلى القيام بذلك:

defer func() {
  if err != nil {
    err = handle(err)
  }
}()

في كلتا الحالتين ، يجب تسمية خطأ الوظيفة الخارجية ليتم الوصول إليها.

كما ذكرت سابقًا في الموضوع ، يمكن تلخيص ذلك في وظيفة واحدة:

func catch(err *error, handle func(error) error) {
  if *err != nil && handle != nil {
    *err = handle(*err)
  }
}

يتعارض هذا مع مخاوفgriesemer بشأن غموض تحويلات المعالج nil ولها defer و func(err error) error boilerplate ، بالإضافة إلى الحاجة إلى تسمية err في الوظيفة الخارجية.

إذا انتهى الأمر بـ try ككلمة رئيسية ، فمن المنطقي أن يكون لديك كلمة رئيسية catch ، على أن يتم وصفها أدناه أيضًا.

من الناحية التركيبية ، سيكون مثل handle :

catch err {
  return handleThe(err)
}

من الناحية الدلالية ، سيكون سكرًا لكود المعالج الداخلي أعلاه:

defer func() {
  if err != nil {
    err = handleThe(err)
  }
}()

نظرًا لأنه سحري إلى حد ما ، فقد يمسك خطأ الوظيفة الخارجية ، حتى لو لم يتم تسميته. (يشبه err بعد catch اسم معلمة للكتلة catch ).

catch سيكون له نفس القيد مثل try الذي يجب أن يكون في دالة لها إرجاع خطأ نهائي ، لأن كلاهما سكر يعتمد على ذلك.

هذا ليس قريبًا من قوة الاقتراح الأصلي handle ، ولكنه سيتجنب مطلب تسمية خطأ من أجل التعامل معه وسيؤدي إلى إزالة النموذج المعياري الجديد الذي تمت مناقشته أعلاه للمعالجات الداخلية مع تسهيل ذلك بما يكفي لعدم تتطلب إصدارات منفصلة من الوظائف للمعالجات الخارجية.

قد تتطلب معالجة الأخطاء المعقدة عدم استخدام catch كما قد يتطلب عدم استخدام try .

نظرًا لأن كلاهما سكر ، فلا داعي لاستخدام catch مع try . يتم تشغيل معالجات catch عندما تقوم الدالة بإرجاع خطأ غير nil ، مما يسمح ، على سبيل المثال ، بالالتزام ببعض التسجيل السريع:

catch err {
  log.Print(err)
  return err
}

أو قم فقط بلف جميع الأخطاء التي تم إرجاعها:

catch err {
  return fmt.Errorf("foo: %w", err)
}

تضمين التغريدة

_ "أعتقد أنها فكرة سيئة ، لأنها تعني أنه إذا تغيرت دالة لإضافة معلمة error لاحقة ، ستستمر الشفرة الحالية في التجميع ، ولكنها ستتصرف بشكل مختلف تمامًا." _

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

لكني أود أن أطلب منكم التفكير فيما يحدث عندما لا يتحكم شخص ما في الحزم الخاصة به في المنبع أو في اتجاه مجرى النهر؟ وأيضًا للنظر في حالات الاستخدام حيث يمكن إضافة الأخطاء ، وماذا يحدث إذا كانت هناك حاجة إلى إضافة أخطاء ولكن لا يمكنك إجبار التعليمات البرمجية النهائية على التغيير؟

هل يمكنك التفكير في مثال يقوم فيه شخص ما بتغيير التوقيع لإضافة قيمة مرتجعة؟ بالنسبة لي ، يقعون عادةً في فئة _ "لم أدرك حدوث خطأ" _ أو _ "أشعر بالكسل ولا أريد بذل الجهد لأن الخطأ لن يحدث على الأرجح". _

في كلتا الحالتين قد أضيف خطأ إرجاع لأنه يصبح من الواضح أنه يجب معالجة خطأ. عندما يحدث ذلك ، إذا لم أتمكن من تغيير التوقيع لأنني لا أريد كسر التوافق مع المطورين الآخرين باستخدام الحزم الخاصة بي ، فماذا أفعل؟ أعتقد أن الغالبية العظمى من الوقت سيحدث الخطأ وأن الكود الذي يسمى func الذي لا يُرجع الخطأ سيعمل بشكل مختلف تمامًا ، _ بأي حال ._

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

من خلال عدم تقديم طريقة متوافقة مع الإصدارات السابقة لإضافة أخطاء لإعادتها بواسطة الوظائف ، لن يتمكن المطورون الذين يوزعون التعليمات البرمجية ويهتمون بعدم كسر الأشياء لمستخدميهم من تطوير حزمهم لتشمل معالجة الأخطاء كما ينبغي.

ربما بدلاً من النظر في المشكلة المتمثلة في أن الكود سيعمل بشكل مختلف بدلاً من النظر إلى المشكلة باعتبارها تحديًا هندسيًا فيما يتعلق بكيفية تقليل الجانب السلبي للطريقة التي لا تلتقط خطأ بشكل نشط؟ سيكون لذلك قيمة أوسع وأطول أجلا.

على سبيل المثال ، ضع في اعتبارك إضافة معالج أخطاء الحزمة الذي يجب على المرء تعيينه قبل التمكن من تجاهل الأخطاء؟

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

لقد انغمسنا نحن Gophers في إرجاع خطأ بدلاً من طرح استثناء ، لذا فإن السؤال الذي أطرحه هو _ "لماذا لا نعيد الأخطاء من كل وظيفة؟" _ لا نفعل ذلك دائمًا لأن كتابة التعليمات البرمجية بدون معالجة الأخطاء هي أكثر ملاءمة من الترميز معها. لذلك نحذف معالجة الأخطاء عندما نعتقد أنه يمكننا الابتعاد عنها. لكن كثيرا ما نخمن خطأ.

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

لم أقترح أي شيء لأنني لم أتمكن من تصور بناء جملة عملي ، ولكن إذا أردنا أن نكون صادقين مع أنفسنا ، فليس كل شيء في هذا الموضوع والمتعلق بمعالجة أخطاء Go بشكل عام حول حقيقة أن معالجة الأخطاء و منطق البرنامج عبارة عن رفقاء غريبين ، لذا فمن الأفضل التعامل مع الأخطاء خارج النطاق بطريقة ما؟

تساعد try ككلمة رئيسية بالتأكيد في سهولة القراءة (مقابل استدعاء الوظيفة) وتبدو أقل تعقيدًا. brynbellomycrawshaw شكرًا لك على الوقت الذي قضيته في كتابة الأمثلة.

أفترض أن تفكيري العام هو أن try يفعل الكثير. إنه يحل: وظيفة الاستدعاء ، وتعيين المتغيرات ، والتحقق من الخطأ ، وإرجاع الخطأ إذا كان موجودًا. أقترح بدلاً من ذلك أن نقطع النطاق ونحل فقط من أجل العودة المشروطة: "العودة إذا كان الجدل الأخير لا شيء".

ربما لا تكون هذه فكرة جديدة ... ولكن بعد تخطي المقترحات في ويكي ملاحظات الخطأ ، لم أجدها (لا يعني أنها ليست موجودة)

اقتراح صغير حول العودة المشروطة

مقتطفات:

err, thing := newThing(name)
refuse nil, err

أضفته إلى الويكي أيضًا تحت عنوان "أفكار بديلة"

يبدو أن عدم القيام بأي شيء هو أيضًا خيار معقول للغاية.

alexhornbake الذي يعطيني فكرة مختلفة قليلاً قد تكون أكثر فائدة

assert(nil, err)
assert(len(a), len(b))
assert(true, condition)
assert(expected, given)

وبهذه الطريقة لن يتم تطبيقه على التحقق من الأخطاء فحسب ، بل ينطبق أيضًا على العديد من أنواع الأخطاء المنطقية.

سيتم تغليف المعطى في خطأ وإعادته.

تضمين التغريدة

تمامًا كما try لا يحاول فعلاً ، فإن refuse ليس "رافضًا" في الواقع. كان القصد المشترك هنا هو أننا نضع "مرحلًا وقائيًا" ( relay قصير ودقيق ومعبّر عن return ) أن "الرحلات" عندما تفي إحدى القيم السلكية بشرط (أي ليس خطأ لا شيء). إنه نوع من قاطع الدائرة ، وأعتقد أنه يمكن أن يضيف قيمة إذا كان التصميم مقصورًا على حالات غير مثيرة للاهتمام لتقليل بعض النماذج المعيارية الأقل تعليقًا. يجب أن يعتمد أي شيء معقد عن بُعد على كود Go العادي.

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

        req.Header = Header(try(tp.ReadMIMEHeader())

سأفتقد كثيرًا أن هذا يمكن أن يخطئ. تحصل القراءة السريعة على "حسنًا ، قم بتعيين الرأس على رأس ReadMimeHeader الخاص بالشيء".

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

هذه ، عيني فقط تحاول تحليل خط OpenDB هذا. هناك كثافة كبيرة هناك ... يوضح هذا المشكلة الرئيسية التي تواجهها جميع استدعاءات الوظائف المتداخلة ، حيث يتعين عليك القراءة من الداخل إلى الخارج ، وعليك تحليلها في رأسك لمعرفة مكان الجزء الأعمق .

لاحظ أيضًا أن هذا يمكن أن يعود من مكانين مختلفين في نفس السطر .. ستعمل على تصحيح الأخطاء ، وسيشير إلى وجود خطأ تم إرجاعه من هذا السطر ، وأول شيء سيفعله الجميع هو محاولة اكتشف سبب فشل OpenDB مع هذا الخطأ الغريب ، في حين أنه في الواقع فشل OpenConnector (أو العكس).

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }   

هذا هو المكان الذي يمكن أن تفشل فيه الشفرة حيث كان من المستحيل في السابق. بدون try ، لا يمكن أن يفشل البناء الحرفي للهيكل. سوف تتصفح عيناي مثل "حسنًا ، إنشاء برنامج تشغيل Stmt ... المضي قدمًا ..." وسيكون من السهل جدًا تفويت ذلك في الواقع ، فقد يتسبب ذلك في حدوث خطأ في وظيفتك. الطريقة الوحيدة التي كان من الممكن أن تكون ممكنة من قبل هي إذا كان ctxDriver مستعدًا للذعر ... ونعلم جميعًا أن هذه الحالة يجب ألا تحدث أبدًا و 2) إذا حدث ذلك ، فهذا يعني أن شيئًا ما خطأ بشكل كبير.

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

daved لست متأكدا من أتابع. هل تكره الاسم أو تكره الفكرة؟

على أي حال ، لقد نشرت هذا هنا كبديل ... إذا كانت هناك مصلحة مشروعة ، يمكنني فتح عدد جديد للمناقشة ، لا أريد تلويث هذا الموضوع (ربما بعد فوات الأوان؟) لنا احساس .. طبعا انفتح على اسماء بديلة. جزء مهم هو "العودة المشروطة دون محاولة التعامل مع التخصيص".

على الرغم من أنني أحب اقتراح الصيد المقدم من jimmyfrasche ، إلا أنني أود اقتراح بديل:
go handler fmt.HandleErrorf("copy %s %s", src, dst)
سيكون معادلاً لـ:
go defer func(){ if(err != nil){ fmt.HandleErrorf(&err,"copy %s %s", src, dst) } }()
حيث Err هو آخر قيمة إرجاع مسماة ، مع نوع الخطأ. ومع ذلك ، يمكن أيضًا استخدام المعالجات عندما لا يتم تسمية قيم الإرجاع. سيتم السماح بالحالة الأكثر عمومية أيضًا:
go handler func(err *error){ *err = fmt.Errorf("foo: %w", *err) }() `
المشكلة الرئيسية التي أواجهها مع استخدام قيم الإرجاع المسماة (التي لا يحلها الصيد) هي أن الخطأ غير ضروري. عند تأجيل مكالمة إلى معالج مثل fmt.HandleErrorf ، لا توجد وسيطة أولية معقولة باستثناء مؤشر إلى قيمة إرجاع الخطأ ، فلماذا إعطاء المستخدم خيار ارتكاب خطأ؟

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

yiyus catch ، كما عرّفته لا يتطلب تسمية err على الوظيفة التي تحتوي على catch .

في catch err { ، فإن err هو ما يسمى الخطأ داخل الكتلة catch . إنه يشبه اسم معلمة الوظيفة.

مع ذلك ، ليست هناك حاجة لشيء مثل fmt.HandleErrorf لأنه يمكنك فقط استخدام fmt.Errorf العادي:

func f() error {
  catch err {
    return fmt.Errorf("foo: %w", err)
  }
  return errors.New("bar")
}

الذي يُرجع خطأ يُطبع كـ foo: bar .

لا أحب هذا النهج للأسباب التالية:

• try() يقوم استدعاء الوظيفة بمقاطعة تنفيذ التعليمات البرمجية في الوظيفة الرئيسية.
• لا توجد كلمة رئيسية return ، لكن الرمز يعود بالفعل.

تم اقتراح العديد من الطرق لعمل المعالجات ، لكنني أعتقد أنهم غالبًا ما يفوتون شرطين رئيسيين:

1. يجب أن يكون مختلفًا بشكل كبير وأفضل من if x, err := thingie(); err != nil { handle(err) } . أعتقد أن الاقتراحات على غرار try x := thingie else err { handle(err) } لا تتوافق مع هذا الشريط. لماذا لا نقول فقط if ؟

2. يجب أن تكون متعامدة مع الوظيفة الحالية defer . أي أنه يجب أن يكون مختلفًا بدرجة كافية بحيث يكون من الواضح أن آلية المناولة المقترحة مطلوبة في حد ذاتها دون إنشاء حالات زاوية غريبة عند التعامل مع التفاعل وتأجيله.

يرجى وضع هذه الرغبات في الاعتبار أثناء مناقشة الآليات البديلة لـ try / handle.

carlmjohnson تعجبني فكرةjimmyfrasche catch بخصوص نقطتك 2 - إنها مجرد بناء جملة sugar لـ defer الذي يحفظ سطرين ويتيح لك تجنب الاضطرار إلى تسمية قيمة إرجاع الخطأ (والتي في بدوره سيتطلب منك أيضًا تسمية كل الآخرين إذا لم تكن قد فعلت ذلك بالفعل). لا تثير مشكلة التعامد مع defer ، لأنها defer .

مرددًا ما قاله ubombi :

try () وظيفة استدعاء المقاطعات تنفيذ التعليمات البرمجية في الدالة الأصل .؛ لا توجد كلمة رئيسية للإرجاع ، لكن الرمز يعود بالفعل.

في Ruby ، ​​تعتبر procs و lambdas مثالاً لما يفعله try ... proc عبارة عن كتلة من التعليمات البرمجية لا تُرجعها عبارة الإرجاع الخاصة بها من الكتلة نفسها ، ولكن من المتصل.

هذا بالضبط ما يفعله try ... إنه مجرد عملية Ruby محددة مسبقًا.

أعتقد أننا إذا كنا سنذهب إلى هذا الطريق ، فربما يمكننا في الواقع السماح للمستخدم بتحديد وظيفة try الخاصة به من خلال تقديم proc functions

ما زلت أفضل if err != nil ، لأنه أكثر قابلية للقراءة ولكن أعتقد أن try سيكون أكثر فائدة إذا حدد المستخدم عملية الشراء الخاصة به:

proc try(err *error, msg string) {
  if *err != nil {
    *err = fmt.Errorf("%v: %w", msg, *err)
    return
  }
}

وبعد ذلك يمكنك تسميتها:

func someFunc() (string, error) {
  err := doSomething()
  try(&err, "someFunc failed")
}

الفائدة هنا ، هي أنك تحصل على تعريف معالجة الأخطاء بشروطك الخاصة. ويمكنك أيضًا جعل proc مكشوفًا أو خاصًا أو داخليًا.

إنها أيضًا أفضل من عبارة handle {} في اقتراح Go2 الأصلي لأنه يمكنك تحديد هذا مرة واحدة فقط لقاعدة الكود بأكملها وليس في كل دالة.

أحد الاعتبارات المتعلقة بقابلية القراءة ، هو أنه قد يتم استدعاء func () و proc () بشكل مختلف مثل func() و proc!() حتى يعرف المبرمج أن استدعاء proc قد يعود فعلاً من وظيفة الاتصال.

@ marwan-at-work ، ألا يجب أن يكون try(err, "someFunc failed") try(&err, "someFunc failed") في مثالك؟

dpinela شكرا على التصحيح ، تحديث الكود :)

الممارسة الشائعة التي نحاول تجاوزها هنا هي ما يقترحه فك المكدس القياسي عبر العديد من اللغات في استثناء ، (ومن هنا تم اختيار كلمة "try" ...).
ولكن إذا كان بإمكاننا السماح فقط بوظيفة (... جرب () أو غير ذلك) من شأنها أن تقفز إلى الوراء مستويين في التتبع ، إذن

try := handler(err error) {     //which corelates with - try := func(err error) 
   if err !=nil{
       //do what ever you want to do when there's an error... log/print etc
       return2   //2 levels
   }
} 

ثم رمز مثل
f: = try (os.Open (filename))
يمكن أن يفعل ما ينصح به الاقتراح تمامًا ، ولكن كدالة (أو في الواقع "وظيفة معالج") ، سيكون لدى المطور قدر أكبر من التحكم في ما تفعله الوظيفة ، وكيفية تنسيق الخطأ في حالات مختلفة ، واستخدام معالج مشابه في كل مكان الكود المطلوب معالجته (دعنا نقول) os.Open ، بدلاً من wrting fmt.Errorf ("خطأ في فتح الملف٪ s ....") في كل مرة.
سيؤدي هذا أيضًا إلى إجبار معالجة الأخطاء كما لو أن "try" لن يتم تعريفها - إنها خطأ في وقت التجميع.

guybrand إن الحصول على مثل هذا العائد على مستويين return2 (أو "عائد غير محلي" كما يطلق على المفهوم العام في Smalltalk) سيكون آلية جيدة للأغراض العامة (اقترحها أيضًا mikeschinkel في # 32473) . ولكن يبدو أن try لا يزال مطلوبًا في اقتراحك ، لذلك لا أرى سببًا لـ return2 - يمكن لـ try تنفيذ return . سيكون الأمر أكثر إثارة للاهتمام إذا كان بإمكان المرء أيضًا كتابة try محليًا ، لكن هذا غير ممكن للتوقيعات العشوائية.

تضمين التغريدة

_ "لذلك لا أرى سببًا لـ return2 - يمكن لـ try تنفيذ return ." _

أحد الأسباب - كما أشرت في # 32473 _ (شكرًا على المرجع) _ - هو السماح بمستويات متعددة من break و continue ، بالإضافة إلى return .

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

إليك ملخص سريع آخر ، هذه المرة أكثر تكثيفًا ؛ أعتذر لمن لم أذكرهم أو نسيتهم أو أسيء تمثيلهم. في هذه المرحلة ، أعتقد أن بعض الموضوعات الأكبر آخذة في الظهور:

1) بشكل عام ، يعتبر استخدام وظيفة مضمنة للوظيفة try اختيارًا سيئًا: نظرًا لأنه يؤثر على تدفق التحكم ، يجب أن يكون _ على الأقل _ كلمة رئيسية (يفضل carloslenz "جعلها عبارة بدون أقواس")؛ try كتعبير لا يبدو فكرة جيدة ، فهو يضر بالقراءة ( ChrisHines ،jimmyfrasche) ، فهي "ترجع بدون return ". أجرىbrynbellomy تحليلًا فعليًا لـ try مستخدمًا كمعرفات ؛ يبدو أن هناك عددًا قليلاً جدًا من النسبة المئوية ، لذلك قد يكون من الممكن استخدام مسار الكلمات الرئيسية بدون التأثير على الكثير من التعليمات البرمجية.

2) استغرقت crawshaw بعض الوقت لتحليل بضع مئات من حالات الاستخدام من مكتبة الأمراض المنقولة جنسياً وتوصلت إلى استنتاج مفاده أن try كما هو مقترح يحسن دائمًا قابلية القراءة. jimmyfrasche وصلوا إلى النتيجة المعاكسة .

3) موضوع آخر هو أن استخدام defer لتزيين الأخطاء ليس مثاليًا. يشير josharian إلى أن defer تعمل دائمًا عند عودة الوظيفة ، ولكن إذا كانوا هنا لتزيين الخطأ ، فنحن نهتم فقط بجسمهم إذا كان هناك خطأ ، والذي قد يكون مصدر ارتباك.

4) كتب العديد اقتراحات لتحسين الاقتراح. zeebo ، @ patrick-nyt يدعمان gofmt تنسيق عبارات بسيطة if في سطر واحد (وكن سعيدًا بالوضع الراهن). اقترح jargv أن try() (بدون وسيطات) قد يُعيد مؤشرًا إلى الخطأ "المعلق" حاليًا ، والذي من شأنه أن يزيل الحاجة إلى تسمية نتيجة الخطأ فقط حتى يتمكن المرء من الوصول إليها في defer ؛ اقترح masterada استخدام errorfunc() بدلاً من ذلك. أعاد velovix فكرة وجود وسيطتين try حيث تكون الوسيطة الثانية عبارة عن معالج أخطاء.

klaidliadon ، @ networkimprov يفضلون "مشغلي المهام" الخاصين مثل f, # := os.Open() بدلاً من try . قدم networkimprov اقتراحًا بديلاً أكثر شمولاً للتحقيق في مثل هذه الأساليب (راجع العدد رقم 32500). قدم mikeschinkel أيضًا اقتراحًا بديلاً يقترح تقديم ميزتين جديدتين للغة للأغراض العامة يمكن استخدامهما لمعالجة الأخطاء أيضًا ، بدلاً من الخطأ المحدد try (راجع المشكلة رقم 32473). أعاد josharian إحياء احتمال ناقشناه في GopherCon العام الماضي حيث لا يعود try عند حدوث خطأ ولكن بدلاً من ذلك يقفز (مع goto ) إلى ملصق يسمى error (بدلاً من ذلك) ، try قد يأخذ اسم التصنيف الهدف).

5) حول موضوع try ككلمة رئيسية ، ظهر سطرين من الأفكار. اقترح brynbellomy إصدارًا قد يحدد المعالج بدلاً من ذلك:

a, b := try f()
a, b := try f() else err { /* handle error */ }

يخطوthepudds خطوة إلى الأمام ويقترح try في بداية السطر ، مما يمنح try نفس الرؤية مثل return :

try a, b := f()

يمكن أن يعمل كلاهما defer .

تضمين التغريدة

شكرًا لك على المرجع إلى mikeschinkel # 32473 ، هناك الكثير من القواسم المشتركة.

بخصوص

ولكن يبدو أن المحاولة لا تزال مطلوبة في اقتراحك
على الرغم من أنه يمكن تنفيذ اقتراحي باستخدام معالج "أي" وليس "بناء" محجوز / كلمة رئيسية / تعبير "لا أعتقد أن" محاولة () "فكرة سيئة (وبالتالي لم تصوت ضدها) ، فأنا أحاول "لتوسيعه" - لذلك سيظهر المزيد من المكاسب ، توقع الكثير "بمجرد تقديم الإصدار 2.0"

أعتقد أن هذا قد يكون أيضًا مصدر "المشاعر المختلطة" التي أبلغت عنها في ملخصك الأخير - إنه ليس "محاولة () لا يحسن معالجة الأخطاء" - متأكد من ذلك ، "انتظار Go 3.0 لحل بعض الأخطاء الرئيسية الأخرى التعامل مع الآلام "المذكورة أعلاه ، تبدو طويلة جدًا :)

أقوم بإجراء دراسة استقصائية حول "آلام التعامل مع الأخطاء" (وأظهر أن بعض الآلام هي مجرد "أنا لا أستخدم الممارسات الجيدة" ، في حين أن البعض لم أتخيل حتى أن الناس (معظمهم من لغات أخرى) يريدون القيام بذلك - بشكل رائع إلى WTF).

آمل أن أتمكن من مشاركة بعض النتائج المثيرة للاهتمام قريبًا.

أخيرًا - شكرًا على العمل الرائع والصبر!

بالنظر ببساطة إلى طول الصيغة الحالية المقترحة مقابل ما هو متاح الآن ، فإن الحالة التي يحتاج فيها الخطأ فقط إلى إرجاعه دون معالجته أو تزيينه هي الحالة التي يتم فيها الحصول على أكبر قدر من الراحة. مثال على النحو المفضل لدي حتى الآن:

try a, b := f() else err { return fmt.Errorf("Decorated: %s", err); }
if a,b, err :=f;  err != nil { return fmt.Errorf("Decorated: %s", err); }
try a, b := f()
if a,b, err :=f;  err != nil { return err; }

لذا ، بخلاف ما اعتقدت من قبل ، ربما يكفي ببساطة تغيير go fmt ، على الأقل بالنسبة لحالة الخطأ المزخرفة / المعالجة. أثناء تخطي حالة الخطأ للتو ، قد يكون شيء مثل المحاولة مرغوبًا فيه مثل السكر النحوي لحالة الاستخدام الشائعة جدًا هذه.

بالنسبة try else ، أعتقد أن وظائف الخطأ الشرطي مثل fmt.HandleErrorf (تحرير: أفترض أنها ترجع صفرًا عندما يكون الإدخال صفرًا) في التعليق الأولي يعمل بشكل جيد ، لذا فإن إضافة else غير ضروري.

a, b, err := doSomething()
try fmt.HandleErrorf(&err, "Decorated "...)

مثل كثيرين هنا ، أفضل أن يكون try عبارة بدلاً من تعبير ، غالبًا لأن التعبير الذي يغير تدفق التحكم يعد غريبًا تمامًا عن Go. أيضًا لأن هذا ليس تعبيرًا ، يجب أن يكون في بداية السطر.

أتفق أيضًا مع daved أن الاسم غير مناسب. بعد كل شيء ، ما نحاول تحقيقه هنا هو مهمة خاضعة للحراسة ، فلماذا لا تستخدم guard مثل Swift وتجعل جملة else اختيارية؟ شيء مثل

GuardStmt = "guard" ( Assignment | ShortVarDecl | Expression ) [  "else" Identifier Block ] .

حيث Identifier هو اسم متغير الخطأ المرتبط بـ Block التالي. مع عدم وجود عبارة else ، فقط قم بالعودة من الوظيفة الحالية (واستخدم معالج التأجيل لتزيين الأخطاء إذا لزم الأمر).

في البداية لم تعجبني عبارة else لأنها مجرد سكر نحوي حول المهمة المعتادة متبوعة بـ if err != nil ، ولكن بعد الاطلاع على بعض الأمثلة ، يكون الأمر منطقيًا: استخدام guard يجعل النية أكثر وضوحًا.

تحرير: اقترح البعض استخدام أشياء مثل catch لتحديد معالجات أخطاء مختلفة بطريقة ما. أجد else قابل للتطبيق بنفس القدر من الناحية اللغوية وهو موجود بالفعل في اللغة.

بينما تعجبني عبارة try-else ، ماذا عن بناء الجملة هذا؟

a, b, (err) := func() else { return err }

التعبير try - else عامل تشغيل ثلاثي.

a, b := try f() else err { ... }
fmt.Println(try g() else err { ... })`

كشف الحساب try - else عبارة عن كشف حساب if .

try a, b := f() else err { ... }
// (modulo scope of err) same as
a, b, err := f()
if err != nil { ... }

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

a, b := try(f(), decorate)
// same as
a, b := try(g())
// where g is
func g() (whatever, error) {
  x, err := f()
  if err != nil {
    try(decorate(err))
  }
  return x, nil
}

كل ثلاثة يقطعون على النمذجة ويساعدون في احتواء نطاق الأخطاء.

إنه يوفر أكبر قدر من المدخرات للمبنى try لكن هذا به المشكلات المذكورة في مستند التصميم.

بالنسبة لكشف الحساب try - else ، فإنه يوفر ميزة على استخدام if بدلاً من try . لكن الميزة هامشية للغاية لدرجة أنني أجد صعوبة في رؤيتها تبرر نفسها ، على الرغم من أنني أحبها.

يفترض الثلاثة أنه من الشائع الحاجة إلى معالجة خطأ خاص للأخطاء الفردية.

يمكن معالجة جميع الأخطاء بالتساوي في defer . إذا تم إجراء معالجة الخطأ نفسها في كل كتلة else فهذا متكرر بعض الشيء:

func printSum(a, b string) error {
  try x := strconv.Atoi(a) else err {
    return fmt.Errorf("printSum: %w", err)
  }
  try y := strconv.Atoi(b) else err {
    return fmt.Errorf("printSum: %w", err)
  }
  fmt.Println("result:", x + y)
  return nil
}

أنا أعلم بالتأكيد أن هناك أوقاتًا يتطلب فيها خطأ معين معالجة خاصة. تلك هي الحالات التي ما زالت بارزة في ذاكرتي. ولكن ، إذا حدث ذلك فقط ، على سبيل المثال ، مرة واحدة من كل 100 مرة ، ألن يكون من الأفضل الاحتفاظ بـ try بسيطًا وعدم استخدام try في تلك المواقف؟ من ناحية أخرى ، إذا كان الأمر أشبه بـ 1 من 10 مرات ، فإن إضافة else / Handler يبدو أكثر منطقية.

سيكون من المثير للاهتمام أن نرى التوزيع الفعلي لعدد المرات try بدون else / معالج مقابل try مع else / معالج سيكون مفيدًا ، على الرغم من ليس من السهل جمع البيانات.

أريد التوسع في تعليقjimmyfrasche الأخير.

الهدف من هذا الاقتراح هو تقليل الصيغة المعيارية

    a, b, err := f()
    if err != nil {
        return nil, err
    }

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

    try a, b := f() else err { return nil, err }

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

    a, b := try(f())

التي تقطع من 56 إلى 18 حرفًا ، وهو تقليل أكثر أهمية. وعلى الرغم من أن عبارة try تجعل التغيير المحتمل لتدفق التحكم أكثر وضوحًا ، بشكل عام لا أجد العبارة أكثر قابلية للقراءة. على الرغم من أنه على الجانب الإيجابي ، فإن عبارة try تجعل من السهل شرح الخطأ.

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

مثل الآخرين ، أود أن أشكر crawshaw على الأمثلة.

عند قراءة هذه الأمثلة ، أشجع الناس على محاولة تبني عقلية لا تقلق فيها بشأن تدفق التحكم بسبب الوظيفة try . أعتقد ، ربما بشكل غير صحيح ، أن تدفق التحكم هذا سيصبح سريعًا طبيعة ثانية للأشخاص الذين يعرفون اللغة. في الحالة العادية ، أعتقد أن الناس سيتوقفون ببساطة عن القلق بشأن ما يحدث في حالة الخطأ. جرب قراءة هذه الأمثلة أثناء التزجيج فوق try تمامًا كما لو كنت تزجج بالفعل فوق if err != nil { return err } .

بعد قراءة كل شيء هنا ، وبعد مزيد من التفكير ، لست متأكدًا من أنني أرى المحاولة حتى كبيان يستحق الإضافة.

1. يبدو أن الأساس المنطقي لذلك هو تقليل معالجة رمز لوحة الغلاية للخطأ. IMHO هو "يبطل" الكود ولكنه لا يزيل التعقيد ؛ إنه يحجبها فقط. هذا لا يبدو قويا بما يكفي لسبب. الذهاب"تم التقاط بناء الجملة بشكل جميل عند بدء سلسلة رسائل متزامنة. لا أفهم هذا النوع من الشعور" آها! "هنا. لا أشعر بالرضا. نسبة التكلفة / الفائدة ليست كبيرة بما يكفي.

2. اسمها لا يعكس وظيفتها. في أبسط أشكالها ، ما تفعله هو: "إذا قامت دالة بإرجاع خطأ ، فارجع من المتصل مع وجود خطأ" ولكن هذا طويل جدًا :-) على الأقل يلزم اسم مختلف.

3. مع الإرجاع الضمني للخطأ في try ، يبدو الأمر وكأن Go هو نوع من الدعم على مضض في معالجة الاستثناءات. هذا إذا كانت مكالمات A في وضع try guard واستدعى B C في حارس try ، واستدعى C D في حارس try ، إذا أرجع D خطأً في الواقع ، فقد تسببت في انتقال غير محلي. إنه شعور "سحري" للغاية.

4. ومع ذلك أعتقد أنه قد يكون من الممكن إيجاد طريقة أفضل. سيؤدي اختيار المحاولة الآن إلى إغلاق هذا الخيار.

تضمين التغريدة
إذا فهمت اقتراح "try else" بشكل صحيح ، فيبدو أن الكتلة else اختيارية ، ومخصصة للمعالجة التي يوفرها المستخدم. في المثال الخاص بك ، try a, b := f() else err { return nil, err } ، عبارة else زائدة عن الحاجة بالفعل ، ويمكن كتابة التعبير بالكامل ببساطة كـ try a, b := f()

أتفق مع ianlancetaylor ،
تعد القابلية للقراءة والنمط المعياري من الاهتمامات الرئيسية وربما الدافع إلى
معالجة أخطاء go 2.0 (على الرغم من أنه يمكنني إضافة بعض المخاوف المهمة الأخرى)

أيضا ، أن التيار

a, b, err := f()
if err != nil {
    return nil, err
}

مقروء للغاية.
ومنذ أن أؤمن

if a, b, err := f(); err != nil {
    return nil, err
}

يكاد يكون مقروءًا ، ولكن به "مشكلات" تتعلق بالنطاق ، ربما أ

ifErr a, b, err := f() {
    return nil, err
}

هذا من شأنه فقط ؛ يخطئ! = لا شيء ، ولن يقوم بإنشاء نطاق ، أو

بصورة مماثلة

جرب أ ، ب ، يخطئ: = f () {
العودة لا شيء ، يخطئ
}

يحتفظ بالسطرين الإضافيين ، لكن لا يزال من الممكن قراءتهما.

في الثلاثاء ، 11 حزيران (يونيو) 2019 ، الساعة 20:19 مساءً ، ديمتري ماترينيتشيف ، [email protected]
كتب:

ianlancetaylor https://github.com/ianlancetaylor
إذا فهمت اقتراح "حاول غير ذلك" بشكل صحيح ، فيبدو أن حظر آخر
اختياري ، ومحجوز للمعالجة المقدمة من المستخدم. في مثالك
جرب أ ، ب: = f () وإلا يخطئ {إرجاع لا شيء ، يخطئ} فإن جملة else هي في الواقع
زائدة عن الحاجة ، ويمكن كتابة التعبير بالكامل ببساطة بتجربة a ، b: =
F()

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/golang/go/issues/32437؟email_source=notifications&email_token=ABNEY4XPURMASWKZKOBPBVDPZ7NALA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63S4DFVREXG43VMVBW63S4DFVREXG43VMVBW63HM
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ABNEY4SAFK4M5NLABF3NZO3PZ7NALANCNFSM4HTGCZ7Q
.

تضمين التغريدة

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

متفق عليه ، وبالنظر إلى أن else سيكون سكرًا نحويًا فقط (مع تركيب غريب!) ، من المحتمل جدًا استخدامه نادرًا ، لا أهتم كثيرًا به. ما زلت أفضل أن يكون try بيانًا بالرغم من ذلك.

ianlancetaylor EchoingDmitriyMV ، ستكون كتلة else اختيارية. دعني أطرح مثالاً يوضح كليهما (ولا يبدو بعيدًا جدًا عن العلامة من حيث النسبة النسبية للكتل التي تم التعامل معها try القطع غير المعالجة في الكود الحقيقي):

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    headRef, err := r.Head()
    if err != nil {
        return err
    }

    parentObjOne, err := headRef.Peel(git.ObjectCommit)
    if err != nil {
        return err
    }

    parentObjTwo, err := remoteBranch.Reference.Peel(git.ObjectCommit)
    if err != nil {
        return err
    }

    parentCommitOne, err := parentObjOne.AsCommit()
    if err != nil {
        return err
    }

    parentCommitTwo, err := parentObjTwo.AsCommit()
    if err != nil {
        return err
    }

    treeOid, err := index.WriteTree()
    if err != nil {
        return err
    }

    tree, err := r.LookupTree(treeOid)
    if err != nil {
        return err
    }

    remoteBranchName, err := remoteBranch.Name()
    if err != nil {
        return err
    }

    userName, userEmail, err := r.UserIdentityFromConfig()
    if err != nil {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    _, err = r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    if err != nil {
        return err
    }
    return nil
}

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    try headRef := r.Head()
    try parentObjOne := headRef.Peel(git.ObjectCommit)
    try parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    try parentCommitOne := parentObjOne.AsCommit()
    try parentCommitTwo := parentObjTwo.AsCommit()
    try treeOid := index.WriteTree()
    try tree := r.LookupTree(treeOid)
    try remoteBranchName := remoteBranch.Name()
    try userName, userEmail := r.UserIdentityFromConfig() else err {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    try r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    return nil
}

بينما لا يحفظ النمط try / else العديد من الأحرف فوق المركب if ، فإنه يفعل:

• توحيد بناء جملة معالجة الخطأ باستخدام try غير المعالج
• أوضح بلمحة أن الكتلة الشرطية تتعامل مع حالة خطأ
• امنحنا فرصة لتقليل غرابة النطاق التي يعاني منها المركب if s

من المحتمل أن يكون try هو الأكثر شيوعًا.

تضمين التغريدة

جرب قراءة هذه الأمثلة أثناء التزجيج بالمحاولة تمامًا كما فعلت بالفعل إذا أخطأت! = لا شيء {إرجاع خطأ}.

لا أعتقد أن هذا ممكن / متساوٍ. في عداد المفقودين وجود المحاولة في سطر مزدحم ، أو ما يلفه بالضبط ، أو أن هناك حالات متعددة في سطر واحد ... هذه ليست هي نفسها بسهولة / بسرعة تحديد نقطة عودة وعدم القلق بشأن التفاصيل الموجودة فيها.

تضمين التغريدة

عندما أرى علامة توقف ، أتعرف عليها من خلال الشكل واللون أكثر من قراءة الكلمة المطبوعة عليها والتفكير في آثارها الأعمق.

قد تتألق عيناي بأكثر من if err != nil { return err } ولكن في نفس الوقت لا تزال تسجل — بوضوح وعلى الفور.

ما يعجبني في المتغير try -statement هو أنه يقلل من الصيغة المعيارية ولكن بطريقة يسهل التزجيج بها ولكن يصعب تفويتها.

قد يعني ذلك سطرًا إضافيًا هنا أو هناك ، لكن هذا لا يزال أقل من سطور الوضع الراهن.

تضمين التغريدة

1. كيف تعرض التعامل مع الدوال التي تُرجع قيمًا متعددة ، مثل:
   func createMergeCommit (r * repo.Repo، index * git.Index، remote * git.Remote، remoteBranch * git.Branch) (التجزئة ، الخطأ) {
2. كيف يمكنك تتبع السطر الصحيح الذي أعاد الخطأ
3. تجاهل مشكلة النطاق (التي يمكن حلها بطرق أخرى) ، لست متأكدًا

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {

    if headRef, err := r.Head(); err != nil {
        return err
    } else if parentObjOne, err := headRef.Peel(git.ObjectCommit); err != nil {
        return err
    } else parentObjTwo, err := remoteBranch.Reference.Peel(git.ObjectCommit); err != nil {
        return err
    } ...

لا تختلف سهولة القراءة من حيث الحكمة ، ومع ذلك (أو fmt.Errorf ("خطأ في الحصول على العنوان:٪ s" ، err.Error ()) يسمح لك بتعديل وإعطاء بيانات إضافية بسهولة.

ما لا يزال تذمر هو

1. الاضطرار إلى إعادة الفحص ؛ يخطئ! = لا شيء
2. إعادة الخطأ كما هو إذا كنا لا نريد تقديم معلومات إضافية - وهي في بعض الحالات ليست ممارسة جيدة ، لأنك تعتمد على الوظيفة التي تستدعيها لتعكس خطأ "جيد" من شأنه أن يلمح إلى "الخطأ الذي حدث "، في حالات file.Open ، والإغلاق ، والإزالة ، ووظائف Db وما إلى ذلك ، يمكن للعديد من استدعاءات الوظائف إرجاع نفس الخطأ (يمكننا القول إذا كان هذا يعني أن المطور الذي كتب الخطأ قام بعمل جيد أم لا ... يحدث) - وبعد ذلك - لديك خطأ ، ربما قم بتسجيله من الوظيفة التي استدعت
   "createMergeCommit" ، لكن لا يمكن تتبعه إلى السطر الذي حدث فيه بالضبط.

عذرًا إذا نشر شخص ما بالفعل شيئًا كهذا (هناك الكثير من الأفكار الجيدة: P) ماذا عن هذه البنية البديلة:

fail := func(err error) error {
  log.Print("unexpected error", err)
  return err
}

a, b, err := f1()          // normal
c, d := f2() -> throw      // calls throw(err)
e, f := f3() -> panic      // calls panic(err)
g, h := f4() -> t.Error    // calls t.Error(err)
i, j := f5() -> fail       // calls fail(err)

وهذا يعني أن لديك -> handler على يمين استدعاء دالة يسمى إذا تم إرجاع الخطأ! = لا شيء. المعالج هو أي دالة تقبل خطأ كوسيطة واحدة وتقوم بشكل اختياري بإرجاع خطأ (على سبيل المثال ، func(error) أو func(error) error ). إذا قام المعالج بإرجاع خطأ لا شيء ، فستستمر الوظيفة وإلا يتم إرجاع الخطأ.

لذا فإن a := b() -> handler يعادل:

a, err := b()
if err != nil {
  if herr := handler(err); herr != nil {
    return herr
  }
}

الآن ، كاختصار ، يمكنك دعم try مدمج (أو كلمة رئيسية أو عامل تشغيل ?= أو أيًا كان) وهو اختصار لـ a := b() -> throw لذا يمكنك كتابة شيء مثل:

func() error {
  a, b := try(f1())
  c, d := try(f2())
  e, f := try(f3())
  ...
  return nil
}() -> panic // or throw/fail/whatever

أنا شخصياً أجد عامل تشغيل ?= أسهل في القراءة من تجربة الكلمة الأساسية / المضمنة:

func() error {
  a, b ?= f1()
  c, d ?= f2()
  e, f ?= f3()
  ...
  return nil
}() -> panic

ملحوظة : هنا أستخدم رمية كعنصر نائب للمدمج الذي سيعيد الخطأ إلى المتصل.

لم أعلق على مقترحات معالجة الأخطاء حتى الآن لأنني أؤيدها بشكل عام ، وأحب الطريقة التي يتجهون بها. يبدو أن كل من وظيفة try المحددة في الاقتراح وبيان try الذي اقترحه thepudds سيكونان إضافات معقولة إلى اللغة. أنا واثق من أن كل ما سيأتي به فريق Go سيكون جيدًا.

أريد أن أتطرق إلى ما أراه مشكلة ثانوية في طريقة تعريف المحاولة في الاقتراح وكيف يمكن أن تؤثر على الامتدادات المستقبلية.

تُعرّف المحاولة بأنها دالة تأخذ عددًا متغيرًا من الوسائط.

func try(t1 T1, t2 T2, … tn Tn, te error) (T1, T2, … Tn)

تمرير نتيجة استدعاء دالة إلى try كما في try(f()) يعمل ضمنيًا بسبب الطريقة التي تعمل بها قيم الإرجاع المتعددة في Go.

من خلال قراءتي للاقتراح ، فإن المقتطفات التالية صحيحة ومتكافئة لغويًا.

a, b = try(f())
//
u, v, err := f()
a, b = try(u, v, err)

يثير الاقتراح أيضًا إمكانية تمديد try مع وسيطات إضافية.

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

افترض أننا نريد إضافة وسيطة معالج. يمكن أن تذهب في بداية قائمة الحجج أو نهايتها.

var h handler
a, b = try(h, f())
// or
a, b = try(f(), h)

لا يعمل وضعه في البداية ، لأنه (بالنظر إلى الدلالات أعلاه) لن يتمكن try من التمييز بين وسيطة المعالج الصريحة والدالة التي ترجع المعالج.

func f() (handler, error) { ... }
func g() (error) { ... }
try(f())
try(h, g())

من المحتمل أن ينجح وضعها في النهاية ، ولكن بعد ذلك ستكون المحاولة فريدة في اللغة باعتبارها الوظيفة الوحيدة مع معلمة varargs في بداية قائمة الوسائط.

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

magical

يعتبر وجود معالج أمرًا قويًا ، ربما:
لقد أعلنت بالفعل ح ،

يمكنك

var h handler
a, b, h = f()

أو

a, b, h.err = f()

إذا كانت تشبه الوظيفة:

h:= handler(err error){
 log(...)
 return ....
} 

ثم كان هناك نداء ل

a, b, h(err) = f()

يمكن للجميع استدعاء المعالج
ويمكنك أيضًا "تحديد" المعالج الذي يقوم بإرجاع أو التقاط الخطأ فقط (conitnue / break / return) كما اقترح البعض.

وهكذا اختفت قضية فارارجس.

أحد البدائل لاقتراح @ brynbellomy else لـ:

a, b := try f() else err { /* handle error */ }

يمكن أن يكون لدعم وظيفة الزخرفة مباشرة بعد الآخر:

decorate := func(err error) error { return fmt.Errorf("foo failed: %v", err) }

try a, b := f() else decorate
try c, d := g() else decorate

وربما تعمل أيضًا بعض الوظائف المفيدة على غرار ما يلي:

decorate := fmt.DecorateErrorf("foo failed")

يمكن أن يكون لوظيفة الزخرفة التوقيع func(error) error ، ويمكن استدعاؤها عن طريق المحاولة في حالة وجود خطأ ، قبل محاولة العودة من الوظيفة المرتبطة التي يتم تجربتها.

سيكون ذلك مماثلاً في الروح لواحد من "تكرارات التصميم" السابقة من وثيقة الاقتراح:

f := try(os.Open(filename), handler)              // handler will be called in error case

إذا أراد شخص ما شيئًا أكثر تعقيدًا أو مجموعة من العبارات ، فيمكنه بدلاً من ذلك استخدام if (تمامًا كما يمكنهم اليوم).

ومع ذلك ، هناك شيء لطيف حول المحاذاة المرئية لـ try الموضحة في مثال @ brynbellomy في https://github.com/golang/go/issues/32437#issuecomment -500949780.

كل هذا يمكن أن يعمل مع defer إذا تم اختيار هذا الأسلوب لتزيين خطأ موحد (أو حتى من الناحية النظرية يمكن أن يكون هناك شكل بديل لتسجيل وظيفة الزخرفة ، ولكن هذه نقطة منفصلة).

على أي حال ، لست متأكدًا من الأفضل هنا ، لكنني أردت توضيح خيار آخر.

إليك مثالbrynbellomy المعاد كتابته باستخدام الدالة try ، باستخدام كتلة var للاحتفاظ بالمحاذاة اللطيفة التي أشار إليها thepudds في https://github.com/golang/go/issues / 32437 # issuecomment -500998690.

package main

import (
    "fmt"
    "time"
)

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    var (
        headRef          = try(r.Head())
        parentObjOne     = try(headRef.Peel(git.ObjectCommit))
        parentObjTwo     = try(remoteBranch.Reference.Peel(git.ObjectCommit))
        parentCommitOne  = try(parentObjOne.AsCommit())
        parentCommitTwo  = try(parentObjTwo.AsCommit())
        treeOid          = try(index.WriteTree())
        tree             = try(r.LookupTree(treeOid))
        remoteBranchName = try(remoteBranch.Name())
    )

    userName, userEmail, err := r.UserIdentityFromConfig()
    if err != nil {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    _, err = r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    return err
}

إنه موجز مثل إصدار بيان try ، وأود أن أجادل بأنه مقروء تمامًا. نظرًا لأن try هو تعبير ، يمكن حذف عدد قليل من تلك المتغيرات الوسيطة ، على حساب بعض المقروئية ، ولكن هذا يبدو وكأنه مسألة أسلوب أكثر من أي شيء آخر.

إنه يثير السؤال حول كيفية عمل try في كتلة var ، على الرغم من ذلك. أفترض أن كل سطر من var يعد بيانًا منفصلاً ، بدلاً من كون الكتلة بأكملها عبارة واحدة ، بقدر ترتيب ما يتم تعيينه ومتى.

سيكون من الجيد إذا دعا اقتراح "المحاولة" صراحةً النتائج المترتبة على أدوات مثل cmd / cover التي تقريبية لإحصائيات تغطية الاختبار باستخدام حساب العبارات الساذج. أخشى أن يؤدي تدفق التحكم في الخطأ غير المرئي إلى تقليل العدد.

تضمين التغريدة

جرب أ ، ب: = f () تزيين آخر

ربما يكون ذلك حرقًا عميقًا جدًا في خلايا دماغي ، لكن هذا يضربني كثيرًا مثل a

try a, b := f() ;catch(decorate)

ومنحدر زلق إلى أ

a, b := f()
catch(decorate)

أعتقد أنه يمكنك معرفة إلى أين يقودنا ذلك ، وبالنسبة لي المقارنة

    try headRef := r.Head()
    try parentObjOne := headRef.Peel(git.ObjectCommit)
    try parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    try parentCommitOne := parentObjOne.AsCommit()
    try parentCommitTwo := parentObjTwo.AsCommit()
    try treeOid := index.WriteTree()
    try tree := r.LookupTree(treeOid)
    try remoteBranchName := remoteBranch.Name()

مع

    try ( 
    headRef := r.Head()
    parentObjOne := headRef.Peel(git.ObjectCommit)
    parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    parentCommitOne := parentObjOne.AsCommit()
    parentCommitTwo := parentObjTwo.AsCommit()
    treeOid := index.WriteTree()
    tree := r.LookupTree(treeOid)
    remoteBranchName := remoteBranch.Name()
    )

(أو حتى الالتقاط في النهاية)
والثاني أكثر قابلية للقراءة ، لكنه يؤكد حقيقة أن الدوال أدناه تعيد متغيرين ، ونحن نتجاهل أحدهما بطريقة سحرية ، ونجمعه في "خطأ إرجاع سحري".

    try(err) ( 
    headRef := r.Head()
    parentObjOne := headRef.Peel(git.ObjectCommit)
    parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    parentCommitOne := parentObjOne.AsCommit()
    parentCommitTwo := parentObjTwo.AsCommit()
    treeOid := index.WriteTree()
    tree := r.LookupTree(treeOid)
    remoteBranchName := remoteBranch.Name()
    ); err!=nil {
      //handle the err
    }

على الأقل يحدد المتغير بشكل صريح للعودة ، واسمحوا لي أن أتعامل معه داخل الوظيفة ، متى أردت.

فقط أقوم بمداخلة تعليق معين لأنني لم أر أي شخص آخر يذكره صراحةً ، وتحديداً حول تغيير gofmt لدعم تنسيق السطر الفردي التالي ، أو أي متغير:

if f() { return nil, err }

من فضلك لا. إذا أردنا سطرًا واحدًا if ، فالرجاء إنشاء سطر واحد if ، على سبيل المثال:

if f() then return nil, err

ولكن من فضلك ، من فضلك ، لا تتبنى سلطة بناء الجملة بإزالة فواصل الأسطر التي تسهل قراءة الكود الذي يستخدم الأقواس.

أود التأكيد على بعض الأشياء التي ربما تم نسيانها في خضم المناقشة:

1) بيت القصيد من هذا الاقتراح هو جعل معالجة الأخطاء الشائعة تتلاشى في الخلفية - يجب ألا يهيمن التعامل مع الأخطاء على الكود. لكن يجب أن تكون صريحة. أي من الاقتراحات البديلة التي تجعل معالجة الخطأ تظهر بشكل أكبر تفتقد إلى الهدف. كما قال ianlancetaylor بالفعل ، إذا لم تقلل هذه الاقتراحات البديلة من مقدار النموذج المعياري بشكل كبير ، فيمكننا فقط البقاء مع بيانات if . (يأتي طلب تقليل النموذج المعياري منك ، مجتمع Go.)

2) إحدى الشكاوى حول الاقتراح الحالي هي الحاجة إلى تسمية نتيجة الخطأ من أجل الوصول إليها. أي اقتراح بديل سيواجه نفس المشكلة ما لم يقدم البديل صياغة إضافية ، أي ، أكثر متداخلة (مثل ... else err { ... } وما شابه) لتسمية هذا المتغير صراحة. ولكن الشيء المثير للاهتمام: إذا كنا لا نهتم بتزيين خطأ ولم نقم بتسمية معلمات النتيجة ، ولكننا ما زلنا نطلب صريحًا return لأن هناك معالجًا واضحًا من نوع ما ، تلك العبارة return سيتعين عليك تعداد جميع قيم النتائج (صفر عادةً) حيث لا يُسمح بالعودة المجردة في هذه الحالة. خاصة إذا كانت الدالة ترجع الكثير من الأخطاء بدون تزيين الخطأ ، فإن هذه العوائد الصريحة ( return nil, err ، إلخ) تضيف إلى النموذج المعياري. الاقتراح الحالي وأي بديل لا يتطلب صراحة return يلغي ذلك. من ناحية أخرى ، إذا كان المرء لا يريد تزيين الخطأ ، فإن الاقتراح الحالي _ يتطلب _ أن يكون اسمًا واحدًا نتيجة الخطأ (ومع ذلك جميع النتائج الأخرى) للوصول إلى قيمة الخطأ. هذا له تأثير جانبي لطيف أنه في المعالج الصريح يمكن للمرء استخدام إرجاع عارية وليس عليه تكرار جميع قيم النتائج الأخرى. (أعلم أن هناك بعض المشاعر القوية حول العوائد المجردة ، ولكن الحقيقة هي أنه عندما يكون كل ما يهمنا هو نتيجة الخطأ ، فمن المزعج الحقيقي أن نضطر إلى تعداد جميع قيم النتائج الأخرى (صفر عادةً) - لا يضيف شيئًا إلى فهم الكود). بعبارة أخرى ، فإن الاضطرار إلى تسمية نتيجة الخطأ بحيث يمكن تزيينها يتيح مزيدًا من تقليل النموذج المعياري.

magical شكرا للإشارة إلى هذا . لقد لاحظت الأمر نفسه بعد فترة وجيزة من نشر الاقتراح (لكنني لم أقم بإحضاره حتى لا يسبب مزيدًا من الارتباك). أنت محق في أنه لا يمكن تمديد try كما هو. لحسن الحظ ، فإن الإصلاح سهل بما فيه الكفاية. (كما يحدث ، لم تواجه مقترحاتنا الداخلية السابقة هذه المشكلة - فقد تم تقديمها عندما أعدت كتابة نسختنا النهائية للنشر وحاولت تبسيط try لمطابقة قواعد تمرير المعلمة الحالية بشكل وثيق. - ولكن كما اتضح ، معيبة ، وغير مجدية في الغالب - فائدة لتكون قادرًا على كتابة try(a, b, c, handle) .)

قام إصدار سابق من try بتعريفه تقريبًا على النحو التالي: يأخذ try(expr, handler) تعبيرًا واحدًا (أو ربما اثنين) كوسيطات ، حيث قد يكون التعبير الأول متعدد القيم (يمكن أن يحدث فقط إذا كان التعبير مكالمة وظيفية). يجب أن تكون القيمة الأخيرة لهذا التعبير (ربما متعدد القيم) من النوع error ، ويتم اختبار هذه القيمة مقابل لا شيء. (إلخ - الباقي يمكنك تخيله).

على أي حال ، فإن النقطة المهمة هي أن try يقبل بشكل نحوي تعبير واحد فقط ، أو ربما تعبيرين. (لكن من الصعب بعض الشيء وصف دلالات try .) ستكون النتيجة تلك الشفرة مثل:

a, b := try(u, v, err)

لن يسمح بعد الآن. ولكن ليس هناك سبب وجيه لإجراء هذا العمل في المقام الأول: في معظم الحالات (ما لم يتم تسمية نتائج a و b ) ، يمكن إعادة كتابة هذا الرمز - إذا كان مهمًا لسبب ما - بسهولة في

a, b := u, v  // we don't care if the assignment happens in case of an error
try(err)

(أو استخدم كشف حساب if حسب الحاجة). لكن مرة أخرى ، هذا يبدو غير مهم.

يجب أن تقوم عبارة الإرجاع هذه بتعداد جميع قيم النتائج (صفر عادةً) حيث لا يُسمح بالعودة المجردة في هذه الحالة

العودة عارية غير مسموح بها ، لكن المحاولة ستكون كذلك. أحد الأشياء التي أحبها في المحاولة (إما كدالة أو بيان) هو أنني لن أحتاج إلى التفكير في كيفية تعيين قيم غير أخطاء عند إرجاع خطأ بعد الآن ، سأستخدم المحاولة.

griesemer شكرا على الشرح. هذا هو الاستنتاج الذي توصلت إليه أيضًا.

تعليق موجز على try كبيان: كما أعتقد يمكن رؤيته في المثال في https://github.com/golang/go/issues/32437#issuecomment -501035322 ، try دفن الديد. يصبح الرمز سلسلة من عبارات try ، مما يحجب ما يفعله الكود بالفعل.

قد تعيد التعليمات البرمجية الحالية استخدام متغير خطأ تم إعلانه حديثًا بعد كتلة if err != nil . قد يؤدي إخفاء المتغير إلى كسر ذلك ، ولن تؤدي إضافة متغير إرجاع مسمى إلى توقيع الوظيفة إلى إصلاحه دائمًا.

ربما يكون من الأفضل ترك إعلان / تعيين الخطأ كما هو ، والعثور على خطأ من سطر واحد في معالجة stmt.

err := f() // followed by one of

on err, return err            // any type can be tested for non-zero
on err, return fmt.Errorf(...)
on err, fmt.Println(err)      // doesn't stop the function
on err, hname err             // handler invocation without parens
on err, ignore err            // optional ignore handler logs error if defined

if err, return err            // alternatively, use if

handle hname(err error, clr caller) { // type caller has results of runtime.Caller()
   if err == io.Bad { return err }
   fmt.Println(clr.name, err)
}

قد يصاب التعبير الجزئي try بالذعر ، مما يعني أن الخطأ غير متوقع أبدًا. البديل من ذلك يمكن أن يتجاهل أي خطأ.

f(try g()) // panic on error
f(try_ g()) // ignore any error

بيت القصيد من هذا الاقتراح هو جعل معالجة الأخطاء الشائعة تتلاشى في الخلفية - يجب ألا تهيمن معالجة الأخطاء على الكود. لكن يجب أن تكون صريحة.

تعجبني فكرة إدراج التعليقات try كبيان. إنه واضح ، ولا يزال من السهل تلميعه (لأنه بطول ثابت) ، ولكن ليس من السهل إخفاءه (لأنه دائمًا في نفس المكان) بحيث يمكن إخفاؤه بعيدًا في خط مزدحم. يمكن أيضًا دمجه مع defer fmt.HandleErrorf(...) كما هو مذكور من قبل ، ومع ذلك فإنه يحتوي على مأزق إساءة استخدام المعلمات المحددة من أجل التفاف الأخطاء (التي لا تزال تبدو وكأنها اختراق ذكي بالنسبة لي. الاختراقات الذكية سيئة.)

أحد الأسباب التي جعلتني لا أحب try كتعبير هو أنه إما أنه من السهل جدًا التستر عليه ، أو أنه ليس من السهل إخفاءه. خذ المثالين التاليين:

جرب كتعبير

// Too hidden, it's in a crowded function with many symbols that complicate the function.

f, err := os.OpenFile(try(FileName()), os.O_APPEND|os.O_WRONLY, 0600)

// Not easy enough, the word "try" already increases horizontal complexity, and it
// being an expression only encourages more horizontal complexity.
// If this code weren't collapsed to multiple lines, it would be extremely
// hard to read and unclear as to what's executing when.

fullContents := try(io.CopyN(
    os.Stdout,
    try(net.Dial("tcp", "localhost:"+try(buf.ReadString("\n"))),
    try(strconv.Atoi(try(buf.ReadString("\n")))),
))

جرب كبيان

// easy to see while still not being too verbose

try name := FileName()
os.OpenFile(name, os.O_APPEND|os.O_WRONLY, 0600)

// does not allow for clever one-liners, code remains much more readable.
// also, the code reads in sequence from top-to-bottom.

try port := r.ReadString("\n")
try lengthStr := r.ReadString("\n")
try length := strconv.Atoi(lengthStr)

try con := net.Dial("tcp", "localhost:"+port)
try io.CopyN(os.Stdout, con, length)

الوجبات الجاهزة

أنا أعترف أن هذا الرمز مفتعل بالتأكيد. لكن ما أفهمه هو أنه ، بشكل عام ، try كتعبير لا يعمل بشكل جيد في:

1. وسط التعبيرات المزدحمة التي لا تحتاج إلى الكثير من تدقيق الأخطاء
2. عبارات متعددة الأسطر بسيطة نسبيًا تتطلب الكثير من التحقق من الأخطاء

ومع ذلك ، أتفق مع ianlancetaylor على أن بدء كل سطر بـ try يبدو أنه يعيق الجزء المهم من كل عبارة (المتغير الذي يتم تعريفه أو الوظيفة التي يتم تنفيذها). ومع ذلك ، أعتقد أنه في نفس الموقع وبعرض ثابت ، فمن الأسهل بكثير إخفاءه ، بينما لا يزال يتم ملاحظته. ومع ذلك ، فإن عيون الجميع مختلفة.

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

fullContents := try(io.CopyN(os.Stdout, try(net.Dial("tcp", "localhost:"+try(r.ReadString("\n"))), try(strconv.Atoi(try(r.ReadString("\n"))))))

يقرأ منفذًا من *bufio.Reader ، ويبدأ اتصال TCP ، وينسخ عددًا من البايتات المحددة بواسطة نفس *bufio.Reader إلى stdout . كل ذلك مع معالجة الأخطاء. بالنسبة للغة ذات اتفاقيات التشفير الصارمة ، لا أعتقد أنه يجب السماح بذلك حقًا. أعتقد أن gofmt يمكن أن يساعد في هذا ، رغم ذلك.

بالنسبة للغة ذات اتفاقيات التشفير الصارمة ، لا أعتقد أنه يجب السماح بذلك حقًا.

من الممكن كتابة كود بغيض في Go. بل من الممكن تنسيقها بشكل رهيب ؛ هناك فقط قواعد وأدوات قوية ضده. الذهاب لديه حتى goto .

أثناء مراجعات الكود ، أطلب أحيانًا من الأشخاص تقسيم التعبيرات المعقدة إلى عبارات متعددة ، بأسماء وسيطة مفيدة. كنت سأفعل شيئًا مشابهًا لـ try s المتداخلة بشدة ، للسبب نفسه.

وهذا هو كل ما يجب قوله: دعونا لا نحاول جاهدين تحريم الشفرات السيئة على حساب تشويه اللغة. لدينا آليات أخرى للحفاظ على الكود نظيفًا أكثر ملاءمة لشيء يتضمن بشكل أساسي حكمًا بشريًا على أساس كل حالة على حدة.

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

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

وهذا هو كل ما يجب قوله: دعونا لا نحاول جاهدين تحريم الشفرات السيئة على حساب تشويه اللغة. لدينا آليات أخرى للحفاظ على الكود نظيفًا أكثر ملاءمة لشيء يتضمن بشكل أساسي حكمًا بشريًا على أساس كل حالة على حدة.