例外和抽象

我希望异常能够按照我要求原始方法所做的事情进行讨论。例如

read -> ReadException
connect -> ConnectException
buildPortfolio -> FailedToBuildPortfolioException

等。这将抽象出封面下发生的事情(即,您是否通过插座等进行连接)。一般来说,当我为组件创建接口时,我通常会创建一个相应的异常或一组异常。我的接口将被调用 Component ,我的例外情况通常是 ComponentException (例如。 RateSource 和 RateSourceException )。它作为一个完整的组件集,易于导出到不同的项目。

在方法调用层次结构(以及异常)的某个时刻,您可能会决定无法进行恢复(或者恢复发生在不适当的位置),并转换为未经检查的异常,以便稍后处理。

我知道这被贴上了“语言不可知论”的标签,但我不认为这是真的。从C++的角度来看,我希望抛出异常的基本操作很少,C++标准库只在很少的地方使用异常。因此,我自己的代码通常是第一个可以生成异常的地方。在这段代码中,我喜欢一个非常扁平的层次结构——我不想在代码后面处理成百上千的catch()子句,而且我从来都不理解Java和C#对创建巴洛克式的类和名称空间继承体系的痴迷。

我认为这里隐藏着两个问题: b) 何时应该对此使用自定义异常。

示例:因为您正在执行一些远程操作,所以会得到ConnectionWhatEverException。

b) 当没有匹配的现有异常时。例如,Java中有几个有用的异常。我经常使用IllegalState和IllegalArgument。新异常类的一个有力参数是,如果您需要提供一些有用的上下文。例如,失败的服务的名称可以是ServiceFailedException的参数。只是不要为每个方法调用创建一个类,或者任何类似的东西。100个异常类不是问题,只要它们具有不同的行为(即至少不同的字段)。如果它们只因名称不同而存在于同一抽象级别上,则将它们设为一个异常,并将不同的名称放入该异常类的消息或单个字段中。

c) 至少在java中有关于检查异常的讨论。我直接用一个未选中的包装,因为我讨厌选中的那种。但这更多的是一种意见,而不是建议。

是否存在非IO问题导致的NoConnectionException的情况?相反,知道原因是否基于IO,是否有助于客户明智地恢复?

注意:在引发原始异常(IOException)的位置可能无法获得此附加信息。抽象的渐进层可能有更多的信息需要添加,比如你试图做什么导致了这个异常?

二,。当您必须不公开实现细节时:例如,您希望(幻觉?)抽象继续。

当底层实现机制可能发生变化时,这一点可能很重要。在自定义异常中包装底层异常是将客户机与实现细节隔离开来的好方法(通过提升抽象级别)

三、 我和我

注意:此外,您的客户应该能够调到他们感兴趣的确切信息级别,或者更确切地说,他们应该能够调出他们不感兴趣的任何内容。因此,从IOException派生自定义异常是一个好主意。