总是在更高级别的对象中捕获异常是一种好习惯吗? [英] Is it good practice to always catch an exception in the higher-level object?

查看:89
本文介绍了总是在更高级别的对象中捕获异常是一种好习惯吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

随着项目变得越来越大,我对于应该抛出什么类型的异常以及应该在哪里捕获异常感到困惑.如何组织内部异常与应向最终用户显示的异常消息.为了减少混乱,最好的做法是始终在更高级别的对象中捕获异常吗?

As a project gets bigger and bigger, I get a bit confused as to what types of exceptions should be thrown and where they should be caught, e.g. how to organize internal exceptions vs exception messages that should be shown to the end user. To keep confusion down, is it best practice to always catch an exception in the higher-level object?

以这个示例为例:如果我有一个数据库类将一个行插入到数据库中,并且该类被另一个处理数据的对象调用,然后该数据处理对象又被一个控制器调用,那么是否正确从处理类的数据库类中捕获错误,哪个(可能)重新抛出要在控制器类中捕获的错误?还是可以在控制器类中捕获数据库类中引发的错误?

Take this example: if I have a database class that inserts a row into the database, and that class is called by another object that processes data, and in turn this data processing object is called by a controller, is it correct to catch errors from the database class in the processing class, which (possibly) rethrows the error to be caught in the controller class? Or can an error thrown in the database class be caught in the controller class?

此外,如果处理类中的一个方法被同一个类中的另一个方法调用,而第一个方法引发错误,则可以在同一个类中捕获异常吗?还是应该将其推迟到调用它的更高级别的类中?

Additionally, if one method in the processing class is called by another method in the same class, and the first throws an error, is it ok to catch the exception in the same class? Or should it be deferred to the higher-level class that's calling it?

在具有多个类级别的大型项目中,还有其他关于如何构造和组织异常的技巧吗?

Are there any other tips on how to structure and organize exceptions in large projects with many levels of classes?

推荐答案

我喜欢将异常视为预期事件,这些异常可能会中断您的正常程序流,但会以一种有序且可控的方式进行. 异常处理的任务是处理这种情况并解决,以使程序状态保持有效并且应用程序可以继续运行.

I like to think about exceptions as expected events that may interrupt your normal program flow but in an orderly and controlled way. The task of your exception handling is to deal with this situation and resolve it in such a way that your program state remains valid and the application can continue.

因此,应该在实际能够解决问题的调用层次结构中的第一个位置添加异常处理. 这可能包括清理不再需要的先前打开的资源,记录事件或向用户提供反馈.

Therefore you should add the exception handling at the first place up the calling hierarchy where you are actually able to resolve the situation. This may include cleaning up previously opened resources which are now no longer needed, logging the event or providing feedback to the user.

在您的示例中,我可能会将处理逻辑留给控制器. 数据库通常没有足够的上下文了解刚刚发生的事情以及如何处理特定条件,因为这些条件取决于调用数据库的上下文. 另一方面,您的控制器应具有所有上下文信息,并且应充分了解该程序刚刚尝试执行的操作. 它也可能更适合解决该问题,例如通过向用户显示一般错误消息,并可能向管理员发送详细的错误报告.

In your example I would probably leave the handling logic to the controller. The database often does not have enough context of what has just happened and how to deal with specific conditions since those depend on the context in which the database has been called. Your controller on the other hand should have all context information and should be well aware of what the program just tried to do. It is also probably better suited to resolve the issue for example by displaying a general error message to the user and maybe send detailed error report to the administrator.

有时候,您还会遇到以下情况:需要在中间级别捕获异常,以进行一些清理(例如关闭流或回滚某些操作),然后重新抛出异常,因为您知道自己只解决了一部分情况.

Sometimes you will also have the situation where you need to catch exception on an intermediate level, to do some cleanup (like closing streams or rolling back some actions) and then rethrow the exception because you know that you did only resolve part of the situation.

总的来说,总体建议是考虑需要采取哪些措施来解决此类异常事件,然后实施错误处理以使这些操作可以轻松完成.

All in all may general recommendation is to think about what actions need to be done to resolve such an exceptional event and then implement the error handling where those actions can be done easily.

这篇关于总是在更高级别的对象中捕获异常是一种好习惯吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆