java - 在应用程序初始化时进行必要和充分的验证

Question

我为您有一个新难题：-)。

 我在思考应用程序应如何处理自己的启动。如：检查所需的库，正确的版本，数据库连接性，数据库兼容性等。具体来说，这里是测试用例。出于明显的原因，我使用SWT和Log4J。现在，问题是：


该应用程序应自行检查所需的依赖项吗？如果是，是否应向用户提供缺少的详细信息？还是只是一条消息，以及日志的详细信息？
如果log4J库不可用怎么办？
什么是最好的测试？验证文件是否存在（使用file.exists（）在指定路径上）或加载类，例如说Class.forName（“ org.apache.log4j.Logger”）？进行检查的正确命令应该是什么？例如，如果我测试SWT，我不知道记录器是否可用，并且当我尝试访问记录器时将发生错误。向后，如果我测试记录器1st：a）库可能不可用-我无法记录错误； b）SWT可能不可用-无法显示用户消息。
我今天发现了apache.commons.lang框架，我发现方法org.apache.commons.lang.SystemUtils.isJavaVersionAtLeast(Float value)非常有用
，还有其他很多人，我确定。但是，将太多的库导入到项目中会不会很难维护？版本更改，兼容性丢失，例如。一个人无法控制第三者的发展风格或方向。


感谢您的回答。

Answer 1

我同意你的需要。检查所需的运行时环境可提供：


立即反馈，而不是在访问某些功能时随机中断
希望有更多熟练的用户，因为即时反馈可供安装软件的人使用，希望比普通用户有更多技能，或者至少没有信心（安装始终是一项特殊的操作）。如果控制台中出现错误，那么熟练的用户就不会受到什么干扰，因为他不依赖于图形界面。
改进的报告功能：错误消息可以是明确的（由您负责），而默认错误消息有多种形式（它们在1.出了什么问题2.建议修复方面并不总是那么有用）。




但是请注意，可以在两种情况下检查运行时要求：


安装时：长时间的验证总是可以接受的;如果库不在此处，则无法访问所需的数据库或WebService，它们也不会在运行时在此处，因此您可以立即进行投诉。
开始执行时：您可以再次进行验证（某些验证可能仅在此时进行）


这建议为您的应用程序创建安装程序。

潜在地，错误不会完全阻止安装。有些人宁愿累积为安装后要完成的任务的清单，也可以将其很好地格式化为包含所有参考信息的文件。

在这里，我们再次达到了验证中错误级别的概念（类似于Log4j的情况）：某些验证错误处于致命级别，其他是错误，也可能是警告...



在我们的项目中，我们在启动时会进行某种初始化和验证。根据我们的日常经验，我建议以下几点：

当应用程序变大时，您不想将所有init集中在一个类中，因此我们有一个模块化的结构。


一个小的内核配置有一系列模块类。它的整个初始化过程都受到严格控制，可以为任何异常做好准备（将它们转换为适当的消息，但记住对开发人员非常有用的堆栈跟踪），无需对可用的库做任何假设，等等。为此代码专门配置的。
模块实现的接口（当然，抽象类是可能的）通常具有几种初始化方法。它们可能是：


getDependencies：返回此模块所依赖的模块列表。
启动：整个应用程序启动时。在启动过程中，它将仅被调用一次，并且不能再次被调用。
开始：模块准备正常运行时
停止：从开始反向
shutdown：从启动相反。

内核依次实例化每个模块。然后，他对所有这些调用一个init方法，然后根据需要调用另一个init方法，依此类推。每个初始化方法可以：


信号错误情况（使用级别，例如Log4J）。
引发的异常将被内核捕获，并转换为错误条件
咨询其他模块的状态（因为通常是依赖关系），并做出相应的反应。如果需要，可以声明方式进行依赖。

内核一般会处理模块依赖性：


他对模块进行排序，以便尊重依赖关系。
如果某个模块的依赖项无法建立模块，则他不会初始化模块。
如果要求停止模块，他将首先停止依赖于该模块的模块。

此内核方法的一个不错的功能是，可以很容易地在各个级​​别上汇总错误（尽管致命错误可以将其停止），并使用任何可用的手段（无论是否SWT，是否使用Log4J，在最后报告所有错误） ...）。因此，您不必一次又一次地发现问题，而不必每次都重新开始，您可以一击即发（当然，这是优先考虑的事情）。




关于您的确切问题：


  该应用程序应自行检查所需的依赖项吗？


是的（请参阅高级）


  如果是，是否应向用户提供缺少的详细信息？还是只是一条消息，以及日志的详细信息？


如上所说，在安装用户时更愿意对此进行处理。

开始时，我们向最终用户使用一条简单的消息，但可以为开发人员提供完整的堆栈跟踪信息（我们有一个按钮可以在剪贴板中复制应用程序环境，堆栈跟踪信息等）。


  如果log4J库不可用怎么办？


不用它登录（请参阅上一节）。


  什么是最好的测试？验证文件是否存在（使用file.exists（）在指定路径上）或加载类，例如说Class.forName（“ org.apache.log4j.Logger”）？


我会上课。但是，如果失败，我可能会检查磁盘上的文件是否存在，以提供改进的消息，包括“如何修复”。


  进行检查的正确命令应该是什么？例如，如果我测试SWT，我不知道记录器是否可用，并且当我尝试访问记录器时将发生错误。向后，如果我测试记录器1st：a）库可能不可用-我无法记录错误； b）SWT可能不可用-无法显示用户消息。


正如我之前所说，建议将这些低级错误累积在一小段代码（内核）中，您可以在其中使用任何可用的显示错误的地方。如果没有可用的内容，则可以直接登录控制台而不使用Log4J。