是否可能通过Java异常公开敏感信息？

当信任边界跨越时，是否可以通过Java

异常

公开敏感的应用程序或系统信息

我的意思是，不仅是理论上，而且如果这发生在真实环境中

e、 g.

java.io.FileNotFoundException

可能会告诉调用者我的应用程序的文件系统结构等。

java.util.ConcurrentModificationException

可能会提供有关我的应用程序的非线程安全类的信息

除以下两种情况外，这种情况是否可以用其他方式处理

使用

Sysouts

（仅使用自定义消息）而不是

引发异常

，以获取其他人应该访问的代码

如果必须抛出异常，请清理消息，然后抛出异常

我还想知道第2点是否完全可以避免，是否不存在抛出异常的强制情况

---

我的问题不是关于任何特定的应用程序，而是一般的编程实践（在大型企业中，如两家不同的银行等，需要应用程序之间的通信）

公开敏感信息的最常见方法是向程序的用户（客户端）提供堆栈跟踪

堆栈跟踪对程序员调试问题很有用，而对其他任何人都不有用。所以日志代码不应该理所当然地输出堆栈跟踪。只有当异常指示程序中存在错误时，它才应该输出它们。它应该将它们输出到程序员可以使用的地方，但输出给尽可能少的其他人

如果一个程序有一个日志文件，该文件对该程序的普通用户不可见，但对管理员可见（服务器就是这样），那么这是记录堆栈跟踪的合适位置

类似的论点也适用于其他敏感信息

尽管您的问题完全是关于安全问题，但这也可以被视为用户体验（用户界面）问题：您向程序的各个用户发送的消息应该适合这些用户，并且应该向他们提供对他们有用的信息。特别是，（但应包括在任何堆栈跟踪中）

对于客户机-服务器程序，客户机对服务器无法处理客户机发送的请求的详细信息不感兴趣。他们需要知道请求确实失败了。如果请求失败是因为服务器出现问题，而不是客户机的错误请求，那么他们需要知道这种情况，以便联系管理员修复服务器。如果请求失败是因为客户端发送了错误的请求，则应告知客户端，并说明请求的错误，以便客户端可以发送更正的请求

---

另外，要注意这一点。如果程序自动处理异常发出的条件，在许多情况下，根本不需要告诉用户异常发出的条件。

我个人认为异常应该始终使用敏感的异常，因为它们还包含stacktrace和其他数据，不应向生产环境中的用户显示异常。但是，将异常提供给使用您的api的人是帮助他们快速调试的一个好方法，您特别是在Java应用程序上下文中的“信任边界”是什么意思（这个术语可以用多种方式解释）。这将有助于给出一个更具体的答案。@ErwinBolwidt-假设一家公司正在托管一个付费java Web服务，供另一个组织左右使用。刚刚删除了一个问题的答案，用户建议编写自己的异常，但输出不太详细。为什么这被认为是不好的做法？我不确定堆栈跟踪是否仍然可见（因为答案被删除得太快，我无法完全理解）。@hamena314:我也看到了，这就是我在讨论的第2点中的意思