محاولة اللحاق كتل مع نوع الإرجاع

Question

وإذا كان لدي أسلوب بإرجاع شيء، مثل

public DataTable ReturnSomething()
{
   try
   {  
      //logic here
     return ds.Tables[0];
   }
   catch (Exception e)
   {
      ErrorString=e.Message;
   }
}

وهذا ينتج الخطأ مترجم، من الواضح لكتلة catch{} لا يرجع أي شيء.

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

Answer 1

وتخزين قيمة عودتك في متغير مؤقت مثل هذا:

public DataTable ReturnSomething()
{
    DataTable returnValue = null;

    try
    {
        //logic here
        returnValue = ds.Tables[0]; 
    }
    catch (Exception e)
    {
        ErrorString=e.Message;
    }

    return returnValue;
}

Answer 2

ويجب رفع / رمي الاستثناء في كتلة الصيد والتعامل معها في طريقة الاستدعاء.

public void invokeFaultyCode()
{
    try
    {
        DataTable dt = ReturnSomething();
    }
    catch(Exception e)
    {
        // Print the error message, cleanup, whatever
    }    
}
public DataTable ReturnSomething() throws Exception
{
   try
   {  
      //logic here
     return ds.Tables[0];
   }
   catch (Exception e)
   {
      ErrorString=e.Message;
      throw;
   }
}

وPS: عذرا عن أي خطأ لغوي، وأنا صدئ قليلا على C #

.

Answer 3

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

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

لبلدي على سبيل المثال، سوف تكون مشفرة هذا على النحو التالي ...

private void DoSomething() {
    try {
        DataTable dt = ReturnSomething();
    }
    catch (Exception ex) {
    }    
}

public DataTable ReturnSomething() {
    DataTable dt = new DataTable();

    // logic here
    return dt;
}

Answer 4

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

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

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

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

Answer 5

إذا كنت تسير على رئاسة "لا رمي طريقا استثناء" (أي أنا لست reccomending بالضرورة)، يمكن اتباع نهج TryParse يستخدم MS.

وشيء من هذا القبيل:

private string FillDataTable(out DataTable results)
{

  try
{
  results = new DataTable(); //something like this;
  return String.Empty;
}
catch (Exception ex)
{
  results = null;
 return ex.Message;

}

و}

Answer 6

وهذا يعتمد عليك التطبيق. يمكنك العودة null، وهو DataTable فارغة أو كل ما هو مناسب في ظل الظروف.

Answer 7

وكنت تحمل لا يزال بإمكانك ضبط الرسالة، ثم يعود لاغية أو أيا كان ج # يعادل هو

public DataTable ReturnSomething(){ 
   try {
        //logic here 
        return ds.Tables[0]; 
   } catch (Exception e) {
        ErrorString=e.Message;
        return null;
   }
}

Answer 8

وماذا عن هذا:

public DataTable ReturnSomething(out string errorString)
{
   errorString = string.Empty;
   DataTable dt = new DataTable();
   try
   {  
      //logic here
     dt = ds.Tables[0];
   }
   catch (Exception e)
   {
      errorString = e.Message;
   }
   return dt;
}

Answer 9

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

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

Answer 10

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

Answer 11

ويمكنك القيام بذلك مثل نموذج التعليمات البرمجية أدناه.

public DataTable ReturnSomething(out string OutputDesc)
{
   try
      {
         //logic here
         OutputDesc = string.Format("Your Successful Message Here...");
         return ds.Tables[0];
      }
      catch (Exception e)
      {
         OutputDesc =e.Message;
         return null;
      }

}