مطالب
فلسفه وجودی بخش finally در try catch چیست؟
حتما شما هم متوجه شدید که وقتی رخداد یک استثناء را با استفاده از try و catch کنترل می‌کنیم، هر چیزی که بعد از بسته شدن تگ catch بنویسیم، در هر صورت اجرا می‌شود.

 try {
     int i=0;
     string s = "hello";
     i = Convert.ToInt32(s);
} catch (Exception ex)
{
     Console.WriteLine("Error");
}
Console.WriteLine("I am here!");

پس فلسفه استفاده از بخش finally چیست؟
در قسمت finally منابع تخصیص داده شده در try را آزاد می‌کنیم. کد موجود در این قسمت به هر روی اجرا می‌شود چه استثناء رخ دهد چه ندهد. البته اگر استثناء رخ داده شده در لیست استثناء هایی که برای آنها catch انجام دادیم نباشد، قسمت finally هم عمل نخواهد کرد مگر اینکه از catch به صورت سراسری استفاده کنیم.
اما مهمترین مزیتی که finally ایجاد می‌کند در این است که حتی اگر در قسمت try با استفاده از دستوراتی مثل return یا break یا continue از ادامه کد منصرف شویم و مثلا مقداری برگردانیم، چه خطا رخ دهد یا ندهد کد موجود در finally اجرا می‌شود در حالی که کد نوشته شده بعد از try catch finally فقط در صورتی اجرا می‌شود که به طور منطقی اجرای برنامه به آن نقطه برسد. اجازه بدهید با یک مثال توضیح دهم. اگر کد زیر را اجرا کنیم:
  public static int GetMyInt()
 {
     try {
          for (int i=10;i>=0;i--)
             Console.WriteLine(10/i);
         return 1;
     } catch
     {
         Console.WriteLine("Error!");
     }
     finally {
         Console.WriteLine("ok");
     }
     Console.WriteLine("can you reach here?");  
     return -1;  
 }

برنامه خطای تقسیم بر صفر می‌دهد اما با توجه به کدی که نوشتیم، عدد -1 به خروجی خواهد رفت. در عین حال عبارت ok و can you reach here در خروجی چاپ شده است. اما حال اگر مشکل تقسیم بر صفر را حل کنیم، آیا باز هم عبارت can you reach here در خروجی چاپ خواهد شد؟
 
public static int GetMyInt()
 {
     try {
          for (int i=10;i>=1;i--)
             Console.WriteLine(10/i);
         return 1;
     } catch
     {
         Console.WriteLine("Error!");
     }
     finally {
         Console.WriteLine("ok");
     }
     Console.WriteLine("can you reach here?");  
     return -1;  
 }

مشاهده می‌کنید که مقدار 1 برگردانده می‌شود و عبارت can you reach here در خروجی چاپ نمی‌شود ولی همچنان عبارت ok که در finally ذکر شده در خروجی چاپ می‌شود. یک مثال خوب استفاده از چنین وضعیتی، زمانی است که شما یک ارتباط با بانک اطلاعاتی باز می‌کنید، و نتیجه یک عملیات را با دستور return به کاربر بر می‌گردانید. مسئله این است که در این وضعیت چگونه ارتباط با دیتابیس بسته شده و منابع آزاد می‌گردند؟ اگر در حین عملیات بانک اطلاعاتی، خطایی رخ دهد یا ندهد، و شما دستور آزاد سازی منابع و بستن ارتباط را در داخل قسمت finally نوشته باشید، وقتی دستور return فراخوانی می‌شود، ابتدا منابع آزاد و سپس مقدار به خروجی بر می‌گردد.
public int GetUserId(string nickname)
{
     SqlConnection connection = new SqlConnection(...);
     SqlCommand command = connection.CreateCommand();
     command.CommandText = "select id from users where nickname like @nickname";
     command.Parameters.Add(new SqlParameter("@nickname", nickname));
      try {
         connection.Open();
          return Convert.ToInt32(command.ExecuteScalar());
      } 
      catch(SqlException exception)
      {
      // some exception handling
         return -1;
      } finally {
          if (connection.State == ConnectionState.Open)
         connection.Close();
      }
      // if all things works, you can not reach here
}


مطالب
توسعه برنامه‌های Cross Platform با Xamarin Forms & Bit Framework - قسمت چهاردهم
در این قسمت قصد داریم به بررسی نحوه‌ی مدیریت خطاها و لاگ کردن آنها بپردازیم. همچنین در ادامه Analytics را در برنامه فعال می‌کنیم تا اطلاعاتی از دستگاه‌های کاربران و ... را به دست بیاوریم (اگر آخرین تغییرات XamApp را Pull/Clone کنید، حاوی تمامی تغییرات زیر است).

در برنامه‌های Native موبایل که شامل Xamarin Forms نیز می‌شود، هر خطایی می‌تواند باعث Crash کردن کل برنامه شود. در Bit Framework، تمامی خطاها مدیریت می‌شوند، تا جلوی بسته شدن برنامه گرفته شود و از این بابت مشکلی متوجه برنامه نمی‌شود و در کدها نیازی به نوشتن Try/Catch هم نیست. خطاها پس از رخ دادن، به کلاس BitExceptionHandler ارسال می‌شوند. شما می‌توانید از این کلاس ارث بری کنید و به شکل زیر حداقل از رخ دادن خطاها در Debug Mode مطلع شوید:
public class XamAppExceptionHandler : BitExceptionHandler
{
     public override void OnExceptionReceived(Exception exp, IDictionary<string, string> properties = null)
      {
#if DEBUG
            System.Diagnostics.Debugger.Break();
#endif
            base.OnExceptionReceived(exp, properties);
      }
}
سپس در ابتدای برنامه‌های Android/iOS/Windows یعنی در فایل‌های MainActivity.cs/AppDelegate.cs/App.xaml.cs کد زیر را برای معرفی کلاس خودتان استفاده کنید:
BitExceptionHandler.Current = new XamAppExceptionHandler();
به صورت پیش فرض، تمامی خطاها را در قسمت System.Diagnostics.Debugger.Break مشاهده خواهید نمود، ولی می‌توانید با باز کردن Exception Settings از منوی Debug > Windows > Exception Settings در ویژوال استودیو و تیک زدن Common Language Runtime Exceptions، تمامی خطاها را در جائیکه رخ می‌دهند، مشاهده کنید که به شما اطلاعات بیشتری نیز می‌دهد.


حال برای لاگ کردن این خطاها، می‌توانید از Microsoft's AppCenter استفاده کنید. استفاده از امکانات App Center رایگان بوده و برای استفاده‌ی در ایران محدودیتی ندارد. ابتدا در سایت مربوطه ثبت نام کنید و سپس سه بار Add New app را بزنید و به نام‌های XamApp_Windows، XamApp_iOS و XamApp_Android سه برنامه را بسازید و برای Android و iOS گزینه‌ی Xamarin را انتخاب و برای ویندوز نیز UWP را انتخاب کنید.

سپس پکیج‌های Microsoft.AppCenter.Crashes و Microsoft.AppCenter.Analytics را بر روی XamApp نصب نموده و کد زیر را در سه فایل AppDelegate.cs/MainActivity.cs/App.xaml.cs برای iOS/Android/Windows کپی کنید:

AppCenter.Start("copy-your-guid-key-for-iOS-Android-Windows-here", typeof(Crashes), typeof(Analytics));

برای هر یک از برنامه‌های Android/iOS/Windows یک Guid متفاوت دارید که در قسمت Getting Started در سایت App Center می‌توانید آنها را مشاهده کنید. هر بار که این کد را کپی می‌کنید، مقدار Guid درست را بگذارید.

برای گزارش کردن خطاهای برنامه، کافی است کد زیر را به XamAppExceptionHandler.cs که در ابتدای این قسمت در موردش صحبت کرده بودیم اضافه کنید:

Crashes.TrackError(exp, properties);

حال اگر برنامه را اجرا و شروع به تست کنید و یا آن را در اختیار تسترها و مشتری‌ها بگذارید، نه تنها گزارش تمامی خطاها و کرش‌ها را خواهید داشت که حتی آمار استفاده کننده‌های برنامه (شامل کشور و مشخصات دستگاه و ...) را نیز خواهید داشت.


حال در یک کد ده خطی، اگر در خط پنجم خطایی رخ دهد، اگر چه باعث بسته شدن برنامه نمی‌شود و لاگ نیز می‌شود، ولی در مواقعی خیلی خاص، شاید بخواهید در صورت رخ دادن خطا، چند خط کد بعدی کماکان اجرا شوند. در این حالت شما Try/Catch می‌نویسید که برای عبور کردن از خطا از آن استفاده کرده‌اید. در این صورت، ترجیحا آن را به شکل زیر بنویسید:

// code 1...
try
{
      // code 2...
}
catch (Exception ex)
{
                BitExceptionHandler.Current.OnExceptionReceived(ex, new Dictionary<string, string>
                {
                    { "SomeData", "2" }
                });
}
// code 3...

در این کد مثال، فرض کنیم که برخی اوقات در code 2 خطایی رخ می‌دهد که برای ما مهم نیست و می‌خواهیم حتی در صورت رخ دادن خطا، code 3 اجرا شود. توصیه می‌کنیم در این موارد که در برنامه خیلی هم نباید متداول باشد، لااقل خطا را با کمک کد BitExceptionHandler.Current.OnExceptionReceived لاگ کنید و همچنین با داشتن یک Dictionary می‌توانید حتی دیتای بیشتری را نیز به AppCenter فرستاده و در پرتال مربوطه مشاهده کنید.

به صورت کلی بهتر است از این نوع Try/Catch‌ها پرهیز کنید و حتی اگر جایی Catch ای نوشتید، در نهایت دوباره خطا را throw کنید.

try
{
     // some codes...
}
catch
{
      // Do something related to exception...
      // for example, show some alerts to the user.
      throw; // You don't need to call BitExceptionHandler.Current.OnExceptionReceived...
}

در مثال فوق، قصد داریم وقتی خطایی رخ داد، پیامی را به کاربر اطلاع دهیم. در این صورت، پس از نمایش پیام مربوطه، مجددا خطا را throw کنید. در این صورت، نیازی به فراخوانی BitExceptionHandler.Current.OnExceptionReceieved نیز نیست.


البته AppCenter در زمینه پابلیش کردن برنامه و همچنین Push Notification و ... نیز دارای امکاناتی هست که به موضوع این قسمت ارتباطی ندارند.

مطالب
تفاوت بین Throw و Throw exception در #C

یکی از سؤالاتی که ممکن است در مصاحبه‌ها با آن روبرو شوید، عنوان این مطلب است. در این مقاله قصد داریم تفاوت بین این دو را بررسی کنیم.

در علم کامپیوتر، یک call stack، یک ساختار داده‌ای پشته می‌باشد که اطلاعات جزئی را راجع به زیرروال‌های فعال یک برنامه، ذخیره می‌کند. این نوع پشته با اسامی مختلفی از جمله Execution Stack (ES)، Program Stack (PS)، Control Stack، Runtime Stack یا Machine Stack شناخته می‌شود و یا اینکه به صورت کلی به آن The Stack یا همان پشته هم می‌گویند. با استفاده از صفحه Call Stack می­توانیم توابع و پروسیجرهایی را که فراخوانی شده‌اند، ببینیم. Call Stack به ما می‌گوید که کدام متدها و توابع، با چه ترتیبی اجرا شده‌اند. Call Stack یک راه بسیار خوب، برای فهم درست نحوه‌ی اجرای یک برنامه است. با رهگیری یا Track کردن Call Stack می­توانیم بفهمیم که مکانیزم کار داخلی برنامه چگونه است و برای بهتر رفع کردن مشکلات، از آن استفاده کنیم. در سی شارپ، Stack Trace یک پشته‌ی اجرایی یا Execution Stack است که تمامی متدهای درحال اجرا را رهگیری (Track) می‌کند. Stack Trace راهی است که با استفاده از آن می‌توانیم  Call Stack را بررسی کنیم، تا شماره خط متدی را که Exception درآن رخ داده است، ببینیم. از این به بعد برای سادگی مطلب، Stack Trace را به صورت ST بیان می‌کنیم. برای دسترسی به ST از فضای نام System.Diagnostics مانند زیر استفاده می‌کنیم.

System.Diagnostics.StackTrace myTrack = new System.Diagnostics.StackTrace();

و یا برای مشاهده‌ی آن در کنسول از کد زیر استفاده میکنیم:

static void Main(string[] args)
{
    Console.WriteLine("Stack Trace: {0}", Environment.StackTrace);
}

نتیجه:

Stack Trace:at System.Environment.get_StackTrace()
 at DiffThrowAndThrowException.Program.Main(String[] args) in Program.cs:line 9


استفاده از ST در Try Catch :

static void Main(string[] args)
{
  try
  {
     throw new Exception();
  }
  catch (Exception ex)
  {
     Console.WriteLine("Stack Trace: {0}", Environment.StackTrace);
  }
}

نتیجه:

Stack Trace:at System.Environment.get_StackTrace()
 at DiffThrowAndThrowException.Program.Main(String[] args) in Program.cs:line 11


حالا که مفهوم Stack Trace و نحوه کار و نمایش آن را بررسی کردیم، به راحتی می‌توان تفاوت بین Throw و Throw Exception را درک کرد. به طور کلی می‌توان اینطور گفت، در حالتیکه در داخل بلاک Catch، از Throw استفاده کنیم، این کار باعث می‌شود استثنائی که در اینجا رخ داده، به ابتدای ST افزوده شده و در واقع سلسله مراتب اجرای برنامه تا جایی که Throw نوشته شده، در ST نگهداری شود. اما در صورتیکه به جای Throw از Throw Exception استفاده کنیم، اتفاقی که رخ می‌دهد این است که ST تا اینجای کار که throw exception را استفاده می‌کنیم، نگهداری میشود و اطلاعات متدهایی که بعد از throw exception اجرا شده‌اند، از آن حذف می‌شود. در نهایت در این حالت ST شامل اطلاعات متدهای اجرا شده در فرآیند جاری، از ابتدا تا رسیدن به throw exception می‌باشد.

در زیر، نمونه کدی را برای استفاده از Throw، می‌بینید:

    class Program
    {
        static void Main(string[] args)
        {
            FirstExceptionMethod firstException = new FirstExceptionMethod();
            try
            {
                firstException.Method1();
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.StackTrace);
            }
        }
    }
    class FirstExceptionMethod
    {
        public void Method1()
        {
            try
            {
                SecondExceptionMethod secondException = new SecondExceptionMethod();
                secondException.Method2();
            }
            catch (Exception ex)
            {
                throw;
            }
        }
    }
    class SecondExceptionMethod
    {
        public void Method2()
        {
            try
            {
                ThrowExMethod();

            }
            catch (Exception ex)
            {
                throw;
            }
        }
        public void ThrowExMethod()
        {
            throw new Exception();
        }
    }  


نتیجه:

at DiffThrowAndThrowException.SecondExceptionMethod.ThrowExMethod() in Program.cs:line 51
   at DiffThrowAndThrowException.SecondExceptionMethod.Method2() in Program.cs:line 41
   at DiffThrowAndThrowException.FirstExceptionMethod.Method1() in Program.cs:line 27
   at DiffThrowAndThrowException.Program.Main(String[] args) in Program.cs:line 12  

همانطور که می‌بینید اطلاعات متدهایی که در این فرآیند اجرا شده‌اند، در داخل Stack Trace رهگیری (track) شده‌اند.


این دفعه برای نشان دادن تفاوت محتویات ST، کدهای Method1 را به شکل زیر تغییر میدهیم که در بخش catch آن، از throw exception استفاده کرده‌ایم:

public void Method1()
        {
            try
            {
                SecondExceptionMethod secondException = new SecondExceptionMethod();
                secondException.Method2();
            }
            catch (Exception ex)
            {
                throw new Exception("Some Text ...");
            }
        }

نتیجه:

   at DiffThrowAndThrowException.FirstExceptionMethod.Method1() in Program.cs:line 31
   at DiffThrowAndThrowException.Program.Main(String[] args) in Program.cs:line 12

در اینجا اطلاعات متدهای برنامه از شروع فرآیند تا جائیکه از throw exception استفاده کرده، در ST نوشته می‌شود.

با دیدن خروجی‌های بالا می‌توان دریافت که استفاده از throw exception بجای throw باعث می‌شود تا اطلاعات کمتری از فرآیند اجرا شده در ST ذخیره شود و در واقع رهگیری متدهای فرآیند از ابتدا تا جائیکه throw exception استفاده می‌شود، پیش میرود و بعد از آن اطلاعاتی را ثبت نمی‌کند.

نظرات مطالب
پردازش‌های Async در Entity framework 6
با سپاس از مقاله شما
بنده در پروژه خود اکثر متدهایی که با سرویس‌ها در ارتباط هستند رو توسط یک متد در  BaseController اجرا میکنم که مدیریت خطا، ارسال نوتیفیکیشن در صورت نیاز و... راحتر صورت بگیره...
  [HttpPost]
        [AjaxOnly]
        public virtual async Task<ActionResult> GetParts([DataSourceRequest] DataSourceRequest request)
        {
            return await DoBaseOperationAsync(() =>
            {
                var result = _partService.GetParts.Where(p => p.IsActive).AsLookupItemModel(p => p.PartId, p => p.CodeName);

                var data = result.ToDataSourceResult(request);
                return Json(data);
            });
        }

که متد DoBaseOperationAsync موجود در Action فوق در BaseController بصورت زیر پیاده سازی شده است.
 protected async Task<ActionResult> DoBaseOperationAsync(Func<ActionResult> func, string title = null, string message = null, MessageType messageType = MessageType.Error)
        {
            try
            {           
                AsyncManager.OutstandingOperations.Increment();

                var cultureInfo = new CultureInfo(CultureHelper.GetCultureString());

                return func != null ? await Task.Factory.StartNew(() =>
                {
                    System.Web.HttpContext.Current = ControllerContext.HttpContext.ApplicationInstance.Context;

                    Thread.CurrentThread.CurrentUICulture = cultureInfo;
                    Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(cultureInfo.Name);

                    return func.Invoke();

                }) : null;

            }
            catch (Exception ex)
            {
                ErrorSignal.FromCurrentContext().Raise(ex);

           // Some code for error handling
            }
        }

حال سوال من این است، اجرا بصورت کد فوق Async تقلبی است (سربار اضافی) یا خیر ؟
آیا میتوان آنرا بهینه کرد که از حالت تقلبی دربیاید ؟
باسپاس./
نظرات مطالب
آماده سازی زیرساخت تهیه Integration Tests برای ServiceLayer
نکته تکمیلی
در پروژه خود از الگوی Container Per Request استفاده می‌کنید؟ برای نزدیکتر کردن شرایط تست به شرایط محیط عملیاتی می‌توان به شکل زیر عمل کرد:
کلاسی برای ایجاد و تخریب Nested Container 
    public static class TestDependencyScope
    {
        private static IContainer _currentNestedContainer;

        public static void Begin()
        {
            if (_currentNestedContainer != null)
                throw new Exception("Cannot begin test dependency scope. Another dependency scope is still in effect.");

            _currentNestedContainer = IoC.Container.GetNestedContainer();
        }

        public static IContainer CurrentNestedContainer
        {
            get
            {
                if (_currentNestedContainer == null)
                    throw new Exception($"Cannot access the {nameof(CurrentNestedContainer)}. There is no dependency scope in effect.");

                return _currentNestedContainer;
            }
        }

        public static void End()
        {
            if (_currentNestedContainer == null)
                throw new Exception("Cannot end test dependency scope. There is no dependency scope in effect.");

            _currentNestedContainer.Dispose();
            _currentNestedContainer = null;
        }
    }

سپس به مانند  AutoRollbackAttrbiute مذکور در مطلب جاری، ContainerPerTestCaseAttribute را برای مدیریت این قضیه در نظر می‌گیریم:
 public class ContainerPerTestCaseAttribute : Attribute, ITestAction
    {   
        public void BeforeTest(ITest test)
        {
            TestDependencyScope.Begin();
        }

        public void AfterTest(ITest test)
        {
            TestDependencyScope.End();
        }

        public ActionTargets Targets => ActionTargets.Test;
    }
و حال نحوه استفاده از آن:
    [PopulateHttpContext]
    [ContainerPerTestCase]
    [Transactional]
    [TestFixture]
    public class IntegratedTestBase
    {
        [SetUp]
        public void EachTestSetUp()
        {
            BeforeEachTest();
        }
        [TearDown]
        public void EachTestTearDown()
        {
            AfterEachTest();
        }
        protected virtual void BeforeEachTest()
        {
        }
        protected virtual void AfterEachTest()
        {
        }

        protected void UsingUnitOfWork(Action<IUnitOfWork> action)
        {
            IoC.Container.Using((IUnitOfWork uow)=>
            {
                uow.DisableAllFilters();
                action(uow);
            });
        }

        protected T UsingUnitOfWork<T>(Func<IUnitOfWork, T> func)
        {
            var uow = IoC.Resolve<IUnitOfWork>();

            uow.DisableAllFilters();

            using (uow)
            {
                var result = func(uow);

                uow.SaveChanges();

                return result;
            }
        }
        protected async Task<T> UsingUnitOfWorkAsync<T>(Func<IUnitOfWork, Task<T>> func)
        {
            var uow = IoC.Resolve<IUnitOfWork>();

            uow.DisableAllFilters();

            using (uow)
            {
                var result = await func(uow).ConfigureAwait(false);

                await uow.SaveChangesAsync().ConfigureAwait(false);

                return result;
            }

        }
    }
و برای دسترسی به Nested Container جاری می‌توان به شکل زیر عمل کرد:
namespace ProjectName.ServiceLayer.IntegrationTests
{
    public static class Testing
    {
        private static IContainer Container => TestDependencyScope.CurrentNestedContainer;

        public static T Resolve<T>()
        {
            return Container.GetInstance<T>();
        }

        public static object Resolve(Type type)
        {
            return Container.GetInstance(type);
        }

        public static void Inject<T>(T instance) where T : class
        {
            Container.Inject(instance);
        }
    }
}

//in test classes
using static ProjectName.ServiceLayer.IntegrationTests.Testing;
namespace ProjectName.ServiceLayer.IntegrationTests
{
    public class RoleServiceTests : IntegratedTestBase
    {
        private IRoleService _service;
        protected override void BeforeEachTest()
        {
            _service = Resolve<IRoleService>();
        }
     }
}

مطالب
فیلترها در MVC
هنگامی که درخواستی به سرور ارسال می‌گردد، به کنترلر و اکشن مربوطه جهت پاسخگویی هدایت می‌شود. خب شاید مواقعی شما نیاز داشته باشید قبل یا بعد از اجرای اکشن متدی، کدی اجرا گردد. به‌همین جهت در MVC قابلیتی بنام Filter ارائه گردید.
فیلتر، یک کلاس سفارشی است که شما می‌توانید منطق برنامه را جهت اجرا، قبل یا بعد از اجرای یک اکشن متد، در آن پیاده سازی نمایید. فیلترها می‌توانند به یک اکشن متد و یا کنترلری منتسب شوند که در ادامه با این روشها آشنا خواهید شد.

در لیست زیر انواع فیلترها و اینترفیس‌هایی که باید توسط کلاس سفارشی شما پیاده سازی شوند، معرفی شده است.

 نوع توضیح
 فیلتر توکار
 اینترفیس
 Authorization
انجام عملیات احراز هویت و سطح دسترسی، قبل از اجرای کد اکشن متد  
 [Authorize] و [RequireHttps]  
 IAuthorizationFilter 
 Action
اجرای کدهایی قبل از اجرای کدهای اکشن متد 
   IActionFilter 
 Result
اجرای کدهایی قبل یا بعد از تولید ویو (View result) 
 [OutputCache]   IResultFilter 
Exception
اجرای کدهایی در صورت وجود استثنای مدیریت نشده 
[HandleError] 
IExceptionFilter
مثال: هنگامی که خطایی در حین اجرای اکشن متدی رخ می‌دهد، فیلتر توکار MVC بنام HandleError اجرا می‌شود. این فیلتر توکار فایل Error.cshtml را که در فولدر Shared قرار دارد، رندر می‌کند و نمایش می‌دهد.
در تکه کد زیر نحوه‌ی استفاده از این فیلتر را مشاهده می‌کنید:
[HandleError]
public class HomeController : Controller
{
    public ActionResult Index()
    {
        //throw exception for demo
        throw new Exception("This is unhandled exception");
            
        return View();
    }

    public ActionResult About()
    {
        return View();
    }

    public ActionResult Contact()
    {
        return View();
    }        
}

نکته: فیلترهای اعمال شده‌ی به یک کنترلر، به تمام اکشن متدهای آن نیز اعمال می‌گردند. 

در کد بالا خصیصه‌ی HandleError به HomeController اعمال شده است. بنابراین در صورت بروز خطایی در هر کدام از اکشن‌ها، صفحه‌ی Error.cshtml نمایش داده خواهد شد و در تظر داشته باشید که خطاها توسط try-catch هندل نشده‌اند.
باید جهت عملکرد صحیح فیلتر توکار HandleErrorAttribute، مقدار customErrors در قسمت System.web فایل web.config مساوی on باشد.
<customErrors mode="On" />


مهیا کنندگان فیلترها

بصورت پیش فرض MVC از سه طریق زیر فیلترها را جهت استفاده‌ی در برنامه فراهم می‌کند:

  1. خصیصه‌ی GlobalFilters.Filters برای فیلترهای سراسری
  2. کلاس FilterAttributeFilterProvider برای فیلترهای خصیصه‌ای
  3. کلاس ControllerInstanceFilterProvider جهت افزودن کنترلر به یک وهله از FilterProviderCollection

در ادامه با نحوه‌ی ایجاد یک فیلتر، بوسیله‌ی هر یک از روش‌های بالا، با ذکر مثالی بیشتر آشنا خواهید شد.

ترتیب اجرای فیلترها

همانطور که در ابتدا اشاره شد، در MVC چهار نوع فیلتر معرفی شده است که امکان استفاده‌ی از آنها به‌صورت همزمان در سطح کنترلر و یا اکشن متد وجود دارد. اما ترتیب  اجرای آنها متفاوت و به ترتیب زیر است:

  1. فیلترهای Authorization
  2. فیلترهای Action
  3. فیلترهای Result یا Response
  4. فیلترهای Exception

فیلترها براساس ترتیب اشاره شده‌ی در بالا اجرا خواهند شد. در صورتیکه چند فیلتر از یک نوع استفاده شود، جهت تقدم و تاخر در اجرا، از خاصیت Order استفاده خواهد شد. بعنوان مثال در کد زیر بدلیل خاصیت Order=1 ابتدا AuthorizationFilterB  و سپس AuthorizationFilterA اجرا می‌شود.

[AuthorizationFilterA(Order=2)]
[AuthorizationFilterB(Order=1)]
public ActionResult Index()
{          
    return View();
}
علاوه بر خاصیت Order، مقدار Scope نیز سطح سومی از ترتیب اجرای فیلترها می‌باشد. مقادیر Scope بشرح زیر است:
public enum FilterScope
{
    First = 0,
    Global = 10,
    Controller = 20,
    Action = 30,
    Last = 100,
}
این خصیصه‌ی فیلترها در محل بکار گیری آنها مقدار دهی می‌شود. در صورتیکه فیلتری بصورت سراسری رجیستر شود، Scope آن برابر 10 و در سطح کنترلر، برابر 20 خواهد بود و الی آخر.

نکته: مقدار Scope فیلترهای Authorization برابر 0 و فیلترهای Exception برابر 100 می‌باشد.

ایجاد فیلتر سفارشی

روش اول: پیاده سازی اینترفیس یکی از انواع فیلترها و ارث بری از کلاس FilterAttribute

در این روش متدهایی که باید پیاده سازی شوند متفاوت خواهد بود. به همین جهت متدهای هر نوع بشرح زیر معرفی می‌شود:

  • IAuthorizationFilter
// Called when authorization is required
void OnAuthorization(AuthorizationContext filterContext)
  • IActionFilter
// Called after the action method executes
void OnActionExecuted(ActionExecutedContext filterContext)

// Called before an action method executes
void OnActionExecuting(ActionExecutingContext filterContext)
  • IResultFilter
// Called after an action result executes
void OnResultExecuted(ResultExecutedContext filterContext)

// Called before an action result executes
void OnResultExecuting(ResultExecutedContext filterContext)
  • IException
// Called when an exception occurs
void OnException(ExceptionContext filterContext)

یادآوری: همانطور که در ابتدای مقاله اشاره شد، فیلترها قبل یا بعد از اجرای اکشن متدها فراخوانی خواهند شد. بنابراین به کامنت بالای متد فیلترها دقت داشته باشید.

مثال: پیاده سازی اینترفیس IExceptionFilter و ارث بری از کلاس FilterAttribute جهت تهیه‌ی فیلتری سفارشی از نوع Exception

class CustomErrorHandler : FilterAttribute, IExceptionFilter
{
    public override void IExceptionFilter.OnException(ExceptionContext filterContext)
    {
        Log(filterContext.Exception);

        base.OnException(filterContext);
    }

    private void Log(Exception exception)
    {
        //log exception here..
    }
}

روش دوم:
ارث بری از ActionFilterAttribute
کلاس abstract فوق دارای چهار متد زیر جهت تحریف است. همانطور که مشاهده می‌کنید این کلاس علاوه بر دو متد OnActionExecuted و OnActionExecuting دارای دو متد دیگر OnResultExecuting و OnResultExecuted که به‌ترتیب قبل و بعد خروجی (Result) اکشن متد اجرا می‌شوند، نیز می‌باشد. این نوع فیلترها عموما جنبه‌ی استفاده عمومی داشته و می‌توان از آنها جهت logging ،caching و یا authorization استفاده کرد.
// Called by MVC after the action method executes
void OnActionExecuted(ActionExecutedContext filterContext)

// Called by MVC before the action method executes
void OnActionExecuted(ActionExecutedContext filterContext)

// Called by MVC after the action result executes
void OnResultExecuted(ResultExecutedContext filterContext)

// Called by MVC before the action result executes
void OnResultExecuting(ResultExecutingContext filterContext)

مثال: کلاس LogAttribute که از کلاس ActionFilterAttribute ارث بری کرده است، عملیات قبل و بعد از اجرای اکشن متد را لاگ می‌کند.
public class LogAttribute : ActionFilterAttribute
{
    public override void OnActionExecuted(ActionExecutedContext filterContext)
    {
        Log("OnActionExecuted", filterContext.RouteData); 
    }

    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        Log("OnActionExecuting", filterContext.RouteData);      
    }

    public override void OnResultExecuted(ResultExecutedContext filterContext)
    {
        Log("OnResultExecuted", filterContext.RouteData);      
    }

    public override void OnResultExecuting(ResultExecutingContext filterContext)
    {
        Log("OnResultExecuting ", filterContext.RouteData);      
    }

    private void Log(string methodName, RouteData routeData)
    {
        var controllerName = routeData.Values["controller"];
        var actionName = routeData.Values["action"];
        var message = String.Format("{0}- controller:{1} action:{2}", methodName, 
                                                                    controllerName, 
                                                                    actionName);
        Debug.WriteLine(message);
    }
}

روش سوم:
پیاده سازی داخل کنترلر
کلاس Controller  می‌تواند هر یک از اینترفیس‌های فیلترها را پیاده سازی نماید. به عبارت دیگر در هر کلاس کنترلر می‌توانید متدهای زیر را تحریف نمایید.
  • OnAuthorization ^
  • OnException ^
  • OnActionExecuting ^
  • OnActionExecuted ^
  • OnResultExecuting ^
  • OnResultExecuted ^


روش چهارم: ارث بری از کلاس فیلترهای توکار و مهیای در MVC و تحریف متدهای آن 
در کد زیر با تحریف و سفارشی سازی متد OnException مخصوص فیلتر توکار HandleError، قابلیت‌های آن افزایش یافته است:

class CustomErrorHandler : HandleErrorAttribute
{
    public override void OnException(ExceptionContext filterContext)
    {
        Log(filterContext.Exception);

        base.OnException(filterContext);
    }

    private void Log(Exception exception)
    {
        //log exception here..
    }
}


رجیستر فیلترها

  • سراسری:

درصورتی که قصد داشته باشید فیلتری بصورت سراسری و در کل برنامه فعال گردد باید آن را در رویداد Application_Start فایل Global.asax.cs بوسیله‌ی متد RegisterGlobalFilters کلاس FiterConfig رجیستر نمایید. بعد از آن فیلتر به کلیه‌ی کنترلرها و اکشن متدها اعمال می‌گردد.

public class MvcApplication : System.Web.HttpApplication
{
    protected void Application_Start()
    {
          FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
    }
}

// FilterConfig.cs located in App_Start folder 
public class FilterConfig
{
    public static void RegisterGlobalFilters(GlobalFilterCollection filters)
    {
        filters.Add(new HandleErrorAttribute());

        // add your new custom filters
        filters.Add(new LogAttribute()); 
        filters.Add(new CustomErrorHandler());
     }
}

در کد بالا فیلتر توکار HandleError و البته فیلترهای سفارشی دیگری نیز به صورت سراسری به تمام اکشن متدهای کنترلرها اعمال گردیده است.

  • کنترلر: در صورتی که فقط بخواهید یک فیلتر به کل اکشن‌های یک کنترلر اعمال گردد. همانند آنچه که در مثال ابتدایی بدان اشاره شد.
[HandleError]
public class HomeController : Controller
  • اکشن متد: اعمال یک فیلتر به یک اکشن متد خاص کنترلر. در کد زیر فیلتر HandleError فقط به اکشن متد Index کنترلر Home اعمال خواهد شد.
public class HomeController : Controller
{
    [HandleError]
    public ActionResult Index()
    {
        return View();
    }
}
مطالب
تکمیل کلاس DelegateCommand

مدت‌ها از کلاس DelegateCommand معرفی شده در این آدرس استفاده می‌کردم. این کلاس یک مشکل جزئی دارد و آن هم عدم بررسی مجدد قسمت canExecute به صورت خودکار هست.

خلاصه‌ای برای کسانی که بار اول هست با این مباحث برخورد می‌کنند؛ یا MVVM به زبان بسیار ساده:

در برنامه نویسی متداول سیستم مایکروسافتی، در هر سیستمی که ایجاد کرده و در هر فناوری که ارائه داده از زمان VB6 تا امروز، شما روی یک دکمه مثلا دوبار کلیک می‌کنید و در فایل اصطلاحا code behind این فرم و در روال رخدادگردان آن شروع به کد نویسی خواهید کرد. این مورد تقریبا در همه جا صادق است؛ از WinForms تا WPF تا Silverlight تا حتی ASP.NET Webforms . به عمد هم این طراحی صورت گرفته تا برنامه نویس‌ها در این محیط‌ها زیاد احساس غریبی نکنند. اما این روش یک مشکل مهم دارد و آن هم «توهم» جداسازی رابط کاربر از کدهای برنامه است. به ظاهر یک فایل فرم وجود دارد و یک فایل جدای code behind ؛ اما در عمل هر دوی این‌ها یک partial class یا به عبارتی «یک کلاس» بیشتر نیستند. «فکر می‌کنیم» که از هم جدا شدند اما واقعا یکی هستند. شما در code behind صفحه به صورت مستقیم با عناصر رابط کاربری سروکار دارید و کدهای شما به این عناصر گره خورده‌اند.
شاید بپرسید که چه اهمیتی دارد؟
مشکل اول: امکان نوشتن آزمون‌ها واحد برای این متدها وجود ندارد یا بسیار سخت است. این متدها فقط با وجود فرم و رابط کاربری متناظر با آن‌ها هست که معنا پیدا می‌کنند و تک تک عناصر آن‌ها وهله سازی می‌شوند.
مشکل دوم: کد نوشته فقط برای همین فرم جاری آن قابل استفاده است؛ چون به صورت صریح به عناصر موجود در فرم اشاره می‌کند. نمی‌تونید این فایل code behind رو بردارید بدون هیچ تغییری برای فرم دیگری استفاده کنید.
مشکل سوم: نمی‌تونید طراحی فرم رو بدید به یک نفر، کد نویسی اون رو به شخصی دیگر. چون ایندو لازم و ملزوم یکدیگرند.

این سیستم کد نویسی دهه 90 است.
چند سالی است که طراحان سعی کرده‌اند این سیستم رو دور بزنند و روش‌هایی رو ارائه بدن که در آن‌ها فرم‌های برنامه و فایل‌های پیاده سازی کننده‌ی منطق آن هیچگونه ارتباط مستقیمی باهم نداشته باشند؛ به هم گره نخورده باشند؛ ارجاعی به هیچیک از عناصر بصری فرم را در خود نداشته باشند. به همین دلیل ASP.NET MVC به وجود آمده و در همان سال‌ها مثلا MVVM .

سؤال:
الان که رابط کاربری از فایل پیاده سازی کننده منطق آن جدا شده و دیگر Code behind هم نیست (همان partial class های متداول)، این فایل‌ها چطور متوجه می‌شوند که مثلا روی یک فرم، شیءایی قرار گرفته؟ از کجا متوجه خواهند شد که روی دکمه‌ای کلیک شده؟ این‌ها که ارجاعی از فرم را در درون خود ندارند.
در الگوی MVVM این سیم کشی توسط امکانات قوی Binding موجود در WPF میسر می‌شود. در ASP.NET MVC چیزی شبیه به آن به نام Model binder و همان مکانیزم‌های استاندارد HTTP این کار رو می‌کنه. در MVVM شما بجای code behind خواهید داشت ViewModel (اسم جدید آن). در ASP.NET MVC این اسم شده Controller. بنابراین اگر این اسامی رو شنیدید زیاد تعجب نکنید. این‌ها همان Code behind قدیمی هستند اما ... بدون داشتن ارجاعی از رابط کاربری در خود که ... اطلاعات موجود در فرم به نحوی به آن‌ها Bind و ارسال می‌شوند.
این سیم کشی‌ها هم نامرئی هستند. یعنی فایل ViewModel یا فایل Controller نمی‌دونند که دقیقا از چه کنترلی در چه فرمی این اطلاعات دریافت شده.
این ایده هم جدید نیست. شاید بد نباشه به دوران طلایی Win32 برگردیم. همان توابع معروف PostMessage و SendMessage را به خاطر دارید؟ شما در یک ترد می‌تونید با مثلا PostMessage شیءایی رو به یک فرم که در حال گوش فرا دادن به تغییرات است ارسال کنید (این سیم کشی هم نامرئی است). بنابراین پیاده سازی این الگوها حتی در Win32 و کلیه فریم ورک‌های ساخته شده بر پایه آن‌ها مانند VCL ، VB6 ، WinForms و غیره ... «از روز اول» وجود داشته و می‌تونستند بعد از 10 سال نیان بگن که اون روش‌های RAD ایی رو که ما پیشنهاد دادیم، می‌شد خیلی بهتر از همان ابتدا، طور دیگری پیاده سازی بشه.

ادامه بحث!
این سیم کشی یا اصطلاحا Binding ، در مورد رخدادها هم در WPF وجود داره و اینبار به نام Commands معرفی شده‌است. به این معنا که بجای اینکه بنویسید:
<Button  Click="btnClick_Event">Last</Button>

بنویسید:
<Button Command="{Binding GoLast}">Last</Button>

حالا باید مکانیزمی وجود داشته باشه تا این پیغام رو به ViewModel برنامه برساند. اینکار با پیاده سازی اینترفیس ICommand قابل انجام است که معرفی یک کلاس عمومی از پیاده سازی آن‌را در ابتدای بحث مشاهده نمودید.
در یک DelegateCommand،‌ توسط متد منتسب به executeAction، مشخص خواهیم کرد که اگر این سیم کشی برقرار شد (که ما دقیقا نمی‌دانیم و نمی‌خواهیم که بدانیم از کجا و کدام فرم دقیقا)، لطفا این اعمال را انجام بده و توسط متد منتسب به canExecute به سیستم Binding خواهیم گفت که آیا مجاز هستی این اعمال را انجام دهی یا خیر. اگر این متد false برگرداند، مثلا دکمه یاد شده به صورت خودکار غیرفعال می‌شود.
اما مشکل کلاس DelegateCommand ذکر شده هم دقیقا همینجا است. این دکمه تا ابد غیرفعال خواهد ماند. در WPF کلاسی وجود دارد به نام CommandManager که حاوی متدی استاتیکی است به نام InvalidateRequerySuggested. اگر این متد به صورت دستی فراخوانی شود، یکبار دیگر کلیه متدهای منتسب به تمام canExecute های تعریف شده، به صورت خودکار اجرا می‌شوند و اینجا است که می‌توان دکمه‌ای را که باید مجددا بر اساس شرایط جاری تغییر وضعیت پیدا کند، فعال کرد. بنابراین فراخوانی متد InvalidateRequerySuggested یک راه حل کلی رفع نقیصه‌ی ذکر شده است.
راه حل دومی هم برای حل این مشکل وجود دارد. می‌توان از رخدادگردان CommandManager.RequerySuggested استفاده کرد. روال منتسب به این رخدادگردان هر زمانی که احساس کند تغییری در UI رخ داده، فراخوانی می‌شود. بنابراین پیاده سازی بهبود یافته کلاس DelegateCommand به صورت زیر خواهد بود:

using System;
using System.Windows.Input;

namespace MvvmHelpers
{
// Ref.
// - http://johnpapa.net/silverlight/5-simple-steps-to-commanding-in-silverlight/
// - http://joshsmithonwpf.wordpress.com/2008/06/17/allowing-commandmanager-to-query-your-icommand-objects/
public class DelegateCommand<T> : ICommand
{
readonly Func<T, bool> _canExecute;
bool _canExecuteCache;
readonly Action<T> _executeAction;

public DelegateCommand(Action<T> executeAction, Func<T, bool> canExecute = null)
{
if (executeAction == null)
throw new ArgumentNullException("executeAction");

_executeAction = executeAction;
_canExecute = canExecute;
}

public event EventHandler CanExecuteChanged
{
add { if (_canExecute != null) CommandManager.RequerySuggested += value; }
remove { if (_canExecute != null) CommandManager.RequerySuggested -= value; }
}

public bool CanExecute(object parameter)
{
return _canExecute == null ? true : _canExecute((T)parameter);
}

public void Execute(object parameter)
{
_executeAction((T)parameter);
}
}
}

استفاده از آن هم در ViewModel ساده است. یکبار خاصیتی به این نام تعریف می‌شود. سپس در سازنده کلاس مقدار دهی شده و متدهای متناظر آن تعریف خواهند شد:

public DelegateCommand<string> GoLast { set; get; }

//in ctor
GoLast = new DelegateCommand<string>(goLast, canGoLast);

private bool canGoLast(string data)
{
//ex.
return ListViewGuiData.CurrentPage != ListViewGuiData.TotalPage - 1;
}

private void goLast(string data)
{
//do something
}

مزیت کلاس DelegateCommand جدید هم این است که مثلا متد canGoLast فوق، به صورت خودکار با به روز رسانی UI ، فراخوانی و تعیین اعتبار مجدد می‌شود.


نظرات مطالب
تبدیل صفحات یک فایل PDF به تصویر، با استفاده از Acrobat SDK
شما زمانیکه قرار هست با نسخه‌ی خط فرمان کار کنید نیازی به هیچ نوع محصور کننده‌ای ندارید.
public static class Cmd
{
    public static int Execute(string filename, string arguments)
    {
        var startInfo = new ProcessStartInfo
        {
            CreateNoWindow = true,
            FileName = filename,
            Arguments = arguments,
        };
        using (var process = new Process { StartInfo = startInfo })
        {
            try
            {
                process.Start();
                process.WaitForExit(30000);
                return process.ExitCode;
            }
            catch (Exception exception)
            {
                if (!process.HasExited)
                {
                    process.Kill();
                }
                return (int)ExitCode.Exception;
            }
        }
    }
}
مطالب
برنامه نویسی Async با ES 6
جاوا اسکریپت به صورت single-thread عمل می‌کند. به این معنا که دو اسکریپت نمی‌توانند به صورت همزمان اجرا شوند و باید یکی پس از دیگری اجرا شوند. ساده‌ترین شکل برنامه‌نویسی غیرهمزمان در جاوا اسکریپت استفاده از callback می‌باشد. به عنوان مثال در سناریوی زیر Caller یکسری عملیات غیرهمزمان را مانند یک فراخوانی XHR و یا یک تایمر، انجام می‌دهد. زمانیکه Caller عملیات غیرهمزمانی را آغاز کرد، یک callback را به آن ارسال خواهد کرد و بعد از مطمئن شدن از موفق بودن عملیات، callback را فراخوانی می‌کند. بعد از پایان عملیات، callback درون call stack قرار خواهد گرفت و هر وقت که بقیه‌ی عملیات به اتمام رسید، اجرا خواهد شد.

این روش چندین مشکل دارد:
  • تنها caller از پایان یافتن عملیات غیرهمزمان مطلع خواهد شد.
  • هندل کردن خطا و همچنین مدیریت چندین عملیات asynchronous به صورت همزمان خیلی سخت خواهد بود.
در اینحالت callback باید به چندین کار رسیدگی کند:
  • پردازش نتایج فراخوانی‌های async
  • اجرای دیگر عملیات براساس پاسخ
کد زیر را در نظر بگیرید:
function getCompanyFromOrderId(orderId) {
    getOrder(orderId, function(order) {
        getUser(order.userId, function(user) {
            getCompany(user.companyId, function(company) {
                // do something with company
            });
        });
    });
}
در کد فوق به اطلاعات یک شرکت براساس شماره سفارش آن دسترسی خواهیم داشت. پس از دریافت سفارش، اطلاعات کاربر را دریافت خواهیم کرد. پس از پایان آن، می‌توانیم به اطلاعات شرکت دسترسی داشته باشیم. این سبک نوشتن کدها به صورت تودرتو خوانایی/ نگهداری کد را کاهش خواهد داد. همانطور که مشاهده می‌کنید callback نه تنها پاسخ بلکه یک callback دیگر را هربار به تابع بعدی ارسال می‌کند. در این‌حالت اگر بخواهیم استثناء‌ها را نیز مدیریت کنیم کدها به مراتب پیچیده‌تر خواهند شد:
function getCompanyFromOrderId(orderId) {
    try {
        getOrder(orderId, function (order) {
            try {
                getUser(order.userId, function (user) {
                    try {
                        getCompany(user.companyId, function (company) {
                            try {
                                // do something with company
                            } catch (ex) {
                                // handle exception
                            }
                        });
                    } catch (ex) {
                        // handle exception
                    }
                });
            } catch (ex) {
                // handle exception
            }
        });
    } catch (ex) {
        // handle exception
    }
}
ممکن است بگوئید که نیازی به این همه try/catch در کد فوق نیست. اما هر callback ایی که به صورت مجزا وارد call stack می‌شود، هر خطایی که صادر شود توسط شروع کننده‌ی اصلی درخواست async به دام انداخته نخواهد شد و در نتیجه نوشتن این همه try/catch ضروری است. لازم به ذکر است، به این نوع نوشتن callback به صورت تودرتو callback hell و یا pyramid of doom نیز گفته می‌شود.

راه‌حل: استفاده از Promises
Promises همیشه به عنوان یک راه‌حل برای callback hell شناخته شده هستند. Promises در واقع اشیایی هستند که این اطمینان را به شما خواهند داد تا بعد از پایان یک عملیات غیرهمزمان، پاسخ را صرفنظر از اینکه عملیات fail و یا success شده باشد، در اختیارتان قرار خواهند داد. یک Promise از دو قسمت تشکیل شده است:
  • Control
  • Promise
قسمت اول یا Control در بیشتر کتابخانه‌ها با نام Deferred نیز از آن نامبرده می‌شود و در واقع یک شیء مستقل است. در بعضی از پیاد‌ه‌سازی‌ها این شیء در واقع خودش یک callback است. قسمت دوم نیز خود Promise است. این شیء می‌تواند دیگر قسمت‌های کد را از پایان یافتن عملیات غیرهمزمان مطلع سازد.
یک Promise می‌تواند یکی از حالت‌های زیر را داشته باشد:
  • pending: یعنی وضعیت اولیه، هنوز به پایان نرسیده است.
  • fulfilled: یعنی عملیات با موفقیت پایان پذیرفته است.
  • rejected: یعنی عملیات با شکست مواجه شده است.
با ایجاد یک Promise، وضعیت آن در اولین مرحله و pending خواهد بود. سپس تبدیل به یکی از وضعیت‌های fulfilled و یا rejected خواهد شد.

اکنون اگر بخواهیم کد قبلی را با استفاده از Promises پیاده‌سازی کنیم به این چنین نتیجه‌ایی خواهیم رسید:
function getCompanyFromOrderId(orderId) {
    getOrder(orderId).then(function(order) {
        return getUser(order.orderId);
    }).then(function(user) {
        return getCompany(user.companyId);
    }).then(function(company) {
        // do something with company
    }).then(undefined, function(error) {
        // handle error
    })
}
در اینجا به جای استفاده از callback در تابع getCompanyFromOrderId یک promise را برمی‌گردانیم. وقتی تابع getOrder با موفقیت کارش را انجام داد، callback بعدی اجرا خواهد شد که در واقع تابع getUser را فراخوانی می‌کند. یک عملیات غیرهمزمان دیگر نیز یک promise را برمی‌گرداند. بعد از آن calback دیگری فراخوانی خواهد شد و به همین ترتیب... در نهایت نیز توسط یک then دیگر می‌توانیم خطاها را هندل کنیم. بنابراین در این‌حالت کد فوق خواناتر و نگهداری آن به مراتب ساده‌تر از حالت قبل می‌باشد.
promises خیلی وقت است که در قالب کتابخانه‌های third-party مانند QwhenWinJSRSVP.js در اختیار برنامه‌نویسان جاوا اسکریپت قرار دارد. در نتیجه کد فوق به صورت جنریک است؛ به این معنا که با هر کدام از کتابخانه‌های عنوان شده سازگاری دارد.

نحوه‌ی ایجاد Promise
ساختار اولیه برای ایجاد یک promise به اینصورت است:
var promise = new Promise(function(resolve, reject) {
  // انجام یکسری عملیات به عنوان مثال دریافت اطلاعات از سرور و...

  if (/* اگر کدهای فوق با موفقیت انجام شدند */) {
    resolve("عملیات با موفقیت انجام پذیرفت");
  }
  else {
    reject(Error("خطایی رخ داده است"));
  }
});
همانطور که مشاهده می‌کنید سازنده‌ی promise یک callback را از ورودی دریافت خواهد کرد. این callback نیز از ورودی دو پارامتر را دریافت میکند: resolve و reject. درون callback می‌توانیم کدهایمان را بنویسیم. بعد از اینکه عملیات با موفقیت انجام گرفت resolve را فراخوانی خواهیم کرد. در غیراینصورت reject را فراخوانی می‌کنیم. همچنین به جای استفاده از throw درون reject از شیء Error استفاده کرده‌ایم. زیرا بعداً برای دیباگ خطا می‌توانیم به اطلاعات کامل stack trace دسترسی داشته باشیم.
در ادامه نحوه‌ی استفاده از promise فوق را مشاهده می‌کنید:
promise.then(function(result) {
  console.log(result); // "عملیات با موفقیت انجام پذیرفت "
}, function(err) {
  console.log(err); // Error: "خطایی رخ داده است"
});
در اینجا تابع then دو آرگومان را از ورودی دریافت خواهد کرد؛ یکی برای حالت success و  دیگری برای حالت failure. لازم به ذکر است، هر دوی این آرگومان‌ها اختیاری هستند.
به عنوان یک مثال عملی می‌توانیم متد get جی‌کوئری را به این صورت درون یک Promise قرار دهیم:
function get(url){
    return new Promise(function(resolve, reject) {
       $.get(url, function(data) {
           resolve(data);
       }) 
       .fail(function(){
          reject(); 
       });
    });
}
به اینصورت می‌توانیم از Promise فوق استفاده کنیم:
get('users.all').then(function(users){
    myController.users = users;
}, function(){
   delete myController.users; 
});
اگر هم مایل بودید می‌توانید به جای ارائه‌ی آرگومان دوم درون callback برای به دام انداختن خطاها از catch استفاده کنید:
get('users.all').then(function(users){
    myController.users = users;
})
.catch(function(){
    delete myController.users;
});

در شرایطی ممکن است بخواهیم بعد از اینکه تمامی Promise هایمان کارشان به اتمام رسید، یکسری عملیات دیگر را انجام دهیم:
var usersPromise = get('users.all');
var postsPromise = get('posts.everyone');

Promise.all([usersPromise, postsPromise])
.then(function(result){
    myController.users = result[0];
    myController.posts = result[1];
}, function(){
   delete myController.users;
   delete myController.posts; 
});
لازم به ذکر است اگر حتی یکی از Promiseها reject شود Promise اصلی نیز reject خواهد شد.

اگر خروجی then به صورت رشته‌ایی باشد چه اتفاقی خواهد افتاد؟
در حالت کلی خروجی هر then. به then بعدی پاس داده خواهد شد. به عنوان مثال در کد زیر نتایج به صورت رشته‌ایی برگردانده خواهند شد و می‌توانیم آن‌ها را به سادگی توسط JSON.parse به then بعدی ارسال کنیم:
get('users.all').then(function(usersString){
    return JSON.parse(usersString);
}).then(function(users){
   myController.users = users; 
});
و یا به صورت خلاصه‌تر می‌توانیم به اینصورت اینکار را انجام دهیم:
get('users.all').then(JSON.parse).then(function(users){
   myController.users = users; 
});
برای مشاهده‌ی دیگر متدهای استاتیک Promise می‌توانید به اینجا مراجعه نمائید.
نظرات مطالب
افزودن یک DataType جدید برای نگه‌داری تاریخ خورشیدی - 1

یک try/catch بذار، تا بتونی تاریخ مشکل دار رو پیدا کنی:

var pers = new PersianCalendar();
var date = pers.ToDateTime(this.Year, this.Month, this.Day, this.Hour, this.Minute, this.Second, 0).ToString();
try
{
   return SqlDateTime.Parse(date);
}
catch(Exception ex)
{
  throw new InvalidOperationException("Can't parse "+ date);
}