当信任边界交叉时，是否可以通过Java Exceptions公开敏感的应用程序或系统信息？
我的意思是，不仅在理论上，而且如果在真实环境中发生这种情况。
e.g。 java.io.FileNotFoundException可能告诉调用者我的应用程序的文件系统结构等。
java.util.ConcurrentModificationException
可能会提供有关我的应用程序的非线程安全类的信息。
这种情况可以用以下两种方式处理吗？
对于其他人应该访问的代码，使用Sysouts（仅使用自定义消息）代替throwing exceptions吗？
如果必须抛出异常，请清理消息然后抛出异常
我也想知道点＃2是否完全可以避免，并且没有任何强制性情况可以抛出异常。
我的问题不是任何特定的应用程序，而是一般的编程实践（在两个不同的银行等大型企业中需要进行应用程序间通信）。
答案 0 :(得分：2)
暴露敏感信息的最常见方式是为程序的用户（客户端）提供堆栈跟踪。
堆栈跟踪对于调试问题的程序员非常有用，而对其他任何人都没有用。因此，日志代码不应该输出堆栈跟踪。只有当异常表明程序中存在错误时，才应输出它们。并且应该将它们输出到程序员可用的地方，但是尽可能少地输出。
如果某个程序的日志文件对程序的正常用户不可见，但管理员可以看到（如服务器的情况），那么这是记录堆栈跟踪的合适位置。
类似的论点适用于其他敏感信息。
虽然您的问题完全是关于安全问题，但这也可以被视为用户体验（用户界面）问题：您向程序的各个用户提供的消息应该适合这些用户，并且应该为他们提供对他们有用的信息without extraneous information that could confuse them。特别是the message text of an exception should not be reported to users（但应作为任何堆栈跟踪的一部分包含在内）。
对于客户端 - 服务器程序，客户端不关心服务器无法处理客户端发送的请求的详细信息。他们需要知道请求确实失败了。如果请求因服务器问题而失败，而不是客户端的错误请求，则需要知道是这种情况，因此他们可以联系管理员来修复服务器。如果请求因客户端发送错误请求而失败，则应告知客户端，并说明请求的错误，以便客户端发送更正的请求。
另外，请注意not all exceptions indicate a problem that some user must be told about。如果程序自动处理由异常发出信号的条件，则在许多情况下，根本不需要告诉用户有关异常发出信号的条件。