我的持久化类应该返回Option还是依赖异常？ [英] Should my persistence class return Option or rely on exceptions?
问题描述
我的应用程序的持久层由存储特征和一个实现类组成。我对此感到不安： fetchFoo（key：Key）方法应该返回 Option [Foo] ，还是如果找不到密钥，他们应该抛出 FooNotFound 异常吗？
My application's persistence layer is formed by a Storage trait and an implementing class. I'm vacillating on this issue: should the fetchFoo(key: Key) methods should return Option[Foo], or should they throw FooNotFound exceptions if the key cannot be found?
为问题增添风味，持久性层-用Scala编写-由Java代码调用。用Java代码处理scala.Option吗？嗯。
To add flavour to the issue, the persistence layer - it is written in Scala - is called by Java code. Dealing with scala.Option in Java code? Hmmm.
事实上，直到昨天，持久层还是用Java编写的；我刚刚在Scala中重写了它。作为Java代码库，它依赖于异常而不是返回null。但是现在我遇到了scala.Option，我正在重新考虑。在我看来，Scala不像Java那样迷恋于异常。
In fact, until yesterday, the persistence layer was written in Java; I've just re-written it in Scala. As a Java code base, it relied on exceptions rather than returning nulls; but now that I've encountered scala.Option, I'm reconsidering. It seems to me that Scala is less enamoured of exceptions than Java.
推荐答案
我对一般问题的看法是，它取决于
My take on the general problem is that it depends on where the keys are coming from.
如果某些用户或不受信任的系统正在输入密钥，那么我将使用 Option 因此我可以有意义地表示未知密钥的可能性，并进行适当处理。
If they are being entered by some user or untrusted system, then I use Option so I can meaningfully denote the possibility of an unknown key and deal with it appropriately.
另一方面，如果密钥来自已知系统（包括诸如嵌入最初来自系统的链接中的键之类的东西，并且被假定为有效并存在，我将其保留为运行时异常，由外部的包罗万象处理。对于链接示例，如果有人出于某种原因手动更改了URL中的密钥，则应将其视为未定义的行为，并应将IMO视为例外。
On the other hand, if the keys are coming from a known system (this includes things like keys embedded in links that originally came from the system), and are assumed to be valid and exist, I would leave it as a runtime exception, handled by a catch-all at the outer level. For the link example, if someone manually changes the key in a url for one reason or another, it should be considered as undefined behaviour and an exception is appropriate, IMO.
另一种思考的方式是当情况出现时如何处理。如果您使用的是 Option ，而只是将 None 案例委派给一些全面的错误处理，那么将出现异常可能更合适。如果您明确捕获了NotFound异常并更改了程序流程（例如，要求用户重新输入密钥），请使用 Option 或已检查的异常（或 Scala中的），以确保情况得到处理。
Another way to think of it is how you would handle the situation when it arises. If you're using Option and are just delegating the None case to some catch-all error handling, then an exception is probably more appropriate. If you're explicitly catching the NotFound exception and altering the program flow (eg, asking the user to re-enter the key), then use Option, or a checked exception (or Either in Scala) to ensure that the situation is dealt with.
与Java集成有关，<一旦Scala运行时库在类路径上可用，就可以从那里轻松使用code> Option 了。另外，在功能Java 库中，有一个 Option 实现。无论如何，我都会避免使用 null 来表示未找到。
In relation to integrating with Java, Option is easy enough to use from there once the Scala runtime library is available on the classpath. Alternatively, there's an Option implementation in the Functional Java library. In any case, I would steer clear of using null to indicate "not found".
这篇关于我的持久化类应该返回Option还是依赖异常？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
