Exceptions当信任边界交叉时，是否可以通过 Java 公开敏感的应用程序或系统信息？
我的意思是，不仅在理论上，而且如果在实际环境中发生这种情况。
例如java.io.FileNotFoundException，可能会告诉调用者我的应用程序的文件系统结构等。
java.util.ConcurrentModificationException
可能会提供有关我的应用程序的非线程安全类的信息。
这种情况是否可以通过以下两种方式处理？
使用Sysouts（仅带有自定义消息）而不是throwing exceptions应该由其他人访问的代码？
如果强制抛出异常，请清理您的消息，然后抛出异常
我还想知道第 2 点是否完全可以避免，并且不会有任何强制情况抛出异常。
我的问题不是关于任何特定的应用程序，而是一般的编程实践（在大型企业中需要应用程序间通信，如两家不同的银行等）。
暴露敏感信息最常见的方法是给程序的用户（客户端）一个堆栈跟踪。
堆栈跟踪对调试问题的程序员很有用，但对其他人没有用。所以日志代码当然不应该输出堆栈跟踪。只有当异常表明程序中有错误时，它才应该输出它们。它应该将它们输出到程序员可以使用的地方，但要尽可能少地提供给其他人。
如果程序有一个日志文件对程序的普通用户不可见但对管理员可见（就像服务器的情况一样），那么这是记录堆栈跟踪的合适位置。
类似的论点适用于其他敏感信息。
尽管您的问题完全是关于安全问题，但这也可以被视为用户体验（用户界面）问题：您向程序的各个用户提供的消息应该适合这些用户，并且应该为他们提供信息对他们有用，没有可能使他们感到困惑的无关信息。特别是，不应向用户报告异常的消息文本（但应作为任何堆栈跟踪的一部分包含在内）。
对于客户端-服务器程序，客户端对服务器未能处理客户端发送的请求的细节不感兴趣。他们需要知道请求确实失败了。如果请求失败是因为服务器的问题，而不是客户端的错误请求，他们需要知道是这种情况，因此他们可以联系管理员修复服务器。如果由于客户端发送了错误请求而导致请求失败，则应告知客户端，并说明请求的错误之处，以便客户端可以发送更正的请求。
此外，请注意，并非所有异常都表示必须告知某些用户的问题。如果程序自动处理异常信号的条件，在许多情况下根本不需要告诉用户异常信号的条件。