API 设计：添加新的异常类型 - 安全吗？
我需要更改现有的服务 API 以针对场景抛出额外的异常。该异常将是已抛出异常的子类型。这样做可以吗？还是会被认为向后不兼容？
我将接口放在一个单独的 jar 中，因此，如果我的服务抛出这个新异常（它是已抛出异常的子级），并且客户端没有新 jar，它会破坏客户端还是他仍然能够捕获该异常吗？像以前一样父异常？
问题是我们有一个非常通用的异常，它会针对每个异常情况抛出，并且一些客户端希望有更好的方法来识别异常 - 除了解析异常中的消息之外，但如果我们引入新的异常，并非所有客户端都可以升级接口- 如何最好地处理这种情况？
谢谢 阿尔温德
I need to change an existing service API to throw an extra exception for a scenario. The exception will be a subtype of an already thrown exception. Is it okay to do this or will it be considered backwards incompatible?
I have the interface in a separate jar, so if my service throws this new exception which is a child of the already thrown one and the client does not have the new jar, will it break the client or will he be able to still catch the parent exception like before?
The problem is we have a very generic exception that is thrown for every exceptional case and some clients want better ways to identify the exception - apart from parsing the message in the exception, but not all clients may upgrade the interface if we introduce a new exception - how best to handle this scenario?
Thanks
Arvind
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
由于新异常是现有异常的子类型，因此您不应破坏任何现有代码。如果客户端代码捕获了基本异常，它将捕获您的新异常。
然后，您可以重构客户端代码以捕获更新的更具体的异常。
As the new exception is a sub-type of an existing one, you shouldn't break any existing code. If the client code traps the base exception it will trap your new one.
You can then refactor the client code to trap the newer more specific exception.