Java:当身份验证例外时我应该/抛出什么?

发布于 2024-12-07 12:41:21 字数 666 浏览 1 评论 0原文

我正在编写一个小型库,其中我需要访问几种不同类型的文件。虽然每种文件格式的访问方法本身都不同,但它们似乎有很多共同点,我在类层次结构中放置了一个接口,在其中编写了一个应该连接到数据源的方法。

然而,由于数据源可能受到密码和/或用户许可的保护,有时需要身份验证才能检索数据。我的问题是:

  1. 在需要身份验证时抛出异常是个好主意吗?

    由于我想尽可能少地公开实现,因此我只想告诉用户发生了什么。但身份验证可能需要许多不同的内容(用户名、密码等),因此我可以将它们打包到一个异常中并将其抛出吗?或者,也许有更好的方法而不诉诸异常,因为“需要身份验证”实际上并不是异常通常用来处理的异常行为。

  2. 需要身份验证时抛出什么异常?

    现在假设我决定使用异常来处理这个问题。我应该抛出哪个异常? Java API 附带的几个 AuthenticationException 似乎不符合此要求,因为它们似乎都非常具体,例如在命名服务中使用。我不确定 SecurityException 是否是正确的方法,但如果这是不正确的,我仍然不想抛出自己的异常,因为这会妨碍其他人理解我的代码以及它是什么API 背后发生的事情。

感谢您的任何意见!这有点冗长或可能太冗长,因此非常欢迎任何可以改善问题的编辑。

I am writing a small library, and in which I need to access several different type of files. While the access method itself is different for each kind of file format, they seem to have a lot in common, and I put an interface in the class hierarchy, in which I wrote a method that should connect to the data source.

However, since the data source might be protected by password and/or user permission, sometimes it need authentication to retrieve the data. My questions are:

  1. It is a good idea to throw an exception when authentication is required?

    Since I want to expose the implementation as little as possible, I only want to tell the user what happened. But authentication might need many different things (username, password, etc.), so could I pack them into one exception and throw it out? Or, maybe there is a better way without resorting to exceptions, since "Authentication required" is not really the exceptional behavior that exception usually used to handle.

  2. What exception to throw when authentication is required?

    Now suppose I decided to use exception to handle this. Which exception should I throw? The several AuthenticationExceptions shipped with Java API does not seem to fit this requirement since they all seem to be very case specific, e.g., used in the naming service. I am not sure if SecurityException is the way to go, but if this is improper, I still really do not want to throw my own exception, since that will impede other people to understand my code and what is going on behind the API.

Thanks for any input! This is somewhat lengthy or maybe too verbose, so any edits that would improve the question is extremely welcomed.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

2024-12-14 12:41:21

AuthenticationException

我会抛出 AuthenticationException 如果需要登录,则显示消息;如果通过不好,则显示用户名或密码错误。

最佳做法是不要透露登录是否存在。有时,在 HTTP 中,使用“未找到”来隐藏未经授权的访问是很常见的。因此,如果凭据不允许连接,就好像连接不存在一样。

AuthenticationException

I would go for throwing AuthenticationException with the message either if the login is needed and username or password wrong if the pass is not good.

It is a best practice to do not disclose whether login exists. And sometimes in HTTP it is common to hide unauthorized access with a not found. So if the credentials do not allow to connect it is like the connection does not exist.

伊面 2024-12-14 12:41:21

由于它是您自己的 API,因此您可以创建自己的异常来配合它,它可以携带详细信息...使用“听起来最接近”您的异常的 Java 异常没有任何要求或好处。

我个人发现在我的代码中添加 try/catch 块是......乏味且难看的。所以我尝试制作不需要它的 API。

在您的情况下,也许您可​​以提供查询,以便您的 API 客户端可以预检操作,它们的用法可能类似于:

Thing t = new Thing(...);
if(t.needsAuth())
{
  boolean ok = t.doPassword("abc123");
  if(!ok)
    log("wrong password");
}
boolean did= t.doIt();
if(!did)
  log("sorry: " + t.getProblem());

Since it's your own API, you might create your own Exception to go with it, which can carry the details... There's no requirement or benefit to using the Java exception that "sounds closest to" your exception.

I personally find that peppering my code with try/catch blocks is... tedious and unsightly. So I try to make API's that don't require it.

In your case, maybe you could provide queries so your API clients could preflight the actions, and their usage might look something like:

Thing t = new Thing(...);
if(t.needsAuth())
{
  boolean ok = t.doPassword("abc123");
  if(!ok)
    log("wrong password");
}
boolean did= t.doIt();
if(!did)
  log("sorry: " + t.getProblem());
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文