Question

在MVC中，管理业务中的异常或错误的最佳方法是什么？我找到了几个解决方案，但不知道选择哪个。

解决方案1 

public Person GetPersonById(string id)
{
    MyProject.Model.Person person = null;
    try
    {
        person = _personDataProvider.GetPersonById(id);
    }
    catch 
    { 
        // I use a try / catch to handle the exception and I return a null value
        // I don't like this solution but the idea is to handle excpetion in 
        // business to always return valid object to my MVC.
        person = null; 
    }
    return person;
}

解决方案2

public Person GetPersonById(string id)
{
    MyProject.Model.Person person = null;
    person = _personDataProvider.GetPersonById(id);
    // I do nothing. It to my MVC to handle exceptions
    return person;
}

解决方案3

public Person GetPersonById(string id, ref MyProject.Technical.Errors errors)
{
    MyProject.Model.Person person = null;
    try
    {
        person = _personDataProvider.GetPersonById(id);
    }
    catch (Exception ex)
    { 
        // I use a try / catch to handle the exception but I return a 
        // collection of errors (or status). this solution allow me to return 
        // several exception in case of form validation.
        person = null; 
        errors.Add(ex); 
    }
    return person;
}

解决方案4

// A better idea ?

Answer 1

让异常在应用程序级别处理。我建议使用解决方案2 。如果要在发生某些异常时更改逻辑，则可以使用try..catch块，否则只需将其留给应用程序基础结构。

Answer 2

我还建议您考虑Null对象模式。而不是返回null，返回一个空对象，这样您就不必执行多次if null检查。您应该创建一个抽象的Person类，它具有静态属性，如NullPerson，它包含默认值。如果您的DAL返回null，您将返回NullPerson。您可以在Null Object Pattern找到更多信息。

Answer 3

应尽快捕获系统错误，而消耗类的每个对象都应实现必要的代码以捕获可能的错误。在最低级别捕获系统错误可让您决定计划执行的操作： - 没有返回值 - 抛出自定义错误 - 重新抛出系统错误

在系统错误和自定义错误之间插入一个抽象层是您可以引入需要不同注意力的新错误。 I.E。：如果错误是FileNotFoundException，您可能希望区分正常错误（即：文件是每日报告但文件asket代表未来报告）或不存在（文件应该存在）

我更倾向于解决方案3，即使在第一阶段，您只需在需要时重新抛出常规异常。

塞尔

Answer 4

这取决于你的要求。

如果您只是想知道我们的流程是否成功执行，那么建议您选择流程2.
如果您愿意写一些错误日志，那么第3步是最佳选择。
如果你不想使用复杂的方法但是你想要处理异常并写入它的日志，那么建议使用进程1。

此致 Pavan.G

在MVC中，管理业务中的异常或错误的最佳方法是什么？

4 个答案: