将 exception.printStackTrace() 函数视为不良写法通常是因为在实际的生产环境中，直接将异常信息打印到标准错误输出（stderr）可能会导致一些问题，包括但不限于以下几点：

不适合生产环境： exception.printStackTrace() 通常用于调试和开发阶段，它将异常堆栈信息直接打印到控制台，使开发人员能够迅速定位问题。然而，在生产环境中，这样的信息通常不应该被公开，因为它可能包含敏感信息，如代码结构和文件路径。

异常信息不易捕获： 使用 exception.printStackTrace() 打印异常信息不方便进行后续处理。在生产环境中，通常需要更灵活地处理异常，例如记录到日志文件、向用户提供友好的错误消息、进行错误恢复等。

不可控的输出： exception.printStackTrace() 将异常信息打印到标准错误输出，这会使异常信息与应用程序的其他输出混合在一起，难以管理和过滤。在生产环境中，通常更喜欢将异常信息记录到专门的日志文件中，以便进行分析和监控。

不符合最佳实践： 在生产环境中，通常会采用更成熟的异常处理和日志记录机制，如使用日志库（如Log4j、Logback）来记录异常。这些库提供了更多的配置选项和性能优化，以适应大规模应用程序的需求。

更好的做法是使用适当的异常处理方法以下：

try {
    // 可能会抛出异常的代码
} catch (Exception e) {
    // 记录异常到日志文件
    logger.error("发生异常：", e);
    // 向用户提供友好的错误消息
    // 进行错误恢复或其他处理
}

exception.printStackTrace() 在开发和调试中仍然有其用途，但在生产代码中，它通常不是最佳的异常处理和日志记录方式。