当信任边界交叉时,是否可以通过
Java Exceptions公开敏感的应用程序或系统信息？

我的意思是,不仅在理论上,而且如果在真实环境中发生这种情况.

例如java.io.FileNotFoundException可能告诉调用者我的应用程序的文件系统结构等.
java.util.ConcurrentModificationException
可能会提供有关我的应用程序的非线程安全类的信息.

这种情况可以用以下两种方式处理吗？

>使用Sysouts(仅使用自定义消息)而不是为其他人访问的代码抛出异常？
>如果强制要求抛出异常,请清理消息然后抛出异常

我也想知道点#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.如果程序自动处理由异常发出信号的条件,则在许多情况下,根本不需要告诉用户有关异常发出信号的情况.