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

• 即时反馈 ,而不是在访问某些功能时随机中断
• 但愿 更熟练的用户
• 改进报告

但请注意,可以在两种情况下检查运行时要求:

• 安装时:长时间验证总是可以接受的;如果库不在这里,所需的数据库或WebService不可访问,它在运行时也不会在这里,因此您可以立即投诉。
• 开始执行时:您可以再次验证(有些验证可能只在此时发生)

潜在地,错误不会全部阻止安装。有些人宁愿在安装后将要完成的任务列表累积起来,也许可以很好地格式化为一个包含所有参考信息的文件。

在我们的项目中,启动时会进行某种初始化和验证。根据我们的日常经验,我建议如下:

当应用程序变大时,您不希望将所有init集中在一个类中,因此我们有一个 模块化结构 .

• 一个小内核配置了以下列表 不做任何假设 在可用库等上…可以为此代码专门配置CheckStyle。

• 模块实现的接口(当然,抽象类也是可能的)通常具有 几种初始化方法 。它们可能是:

  • startup:整个应用程序启动时。启动时只会调用一次,不能再次调用。
  • 停止:从开始反向
  • 关机:与启动相反。

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

• :

  • 他对模块进行排序,以尊重依赖关系。
  • 如果模块的某个依赖项无法创建,他不会初始化模块。

• 汇总错误 在各个层面(尽管 致命的

是(见上文)

如果是,是否应该向用户提供缺失内容的具体细节?或者只是一条消息,以及日志的详细信息?

开始时,我们为最终用户使用一条简单的消息,但允许开发人员访问完整的堆栈跟踪(我们有一个按钮,可以在剪贴板中复制应用程序环境、堆栈跟踪等)。

如果log4J库不可用怎么办?

正如我前面所说的,我建议这些低级错误累积在一小部分代码(内核)中,在那里你可以使用任何可用的东西来显示它们。如果没有可用信息,您可以在没有Log4J的情况下登录控制台。

• 应用程序打包不在您的控制之下,您需要交付主jar和关于需求的说明。运行时验证可能很有用,但想要打包应用程序的人通常有足够的技能来理解 ClassNotFoundException: org.apache.logging.LogManager 意味着。

关于4,只要你保持项目中包含的依赖项的相同版本,你在保持控制方面就没有问题。升级到新版本是一个有意识的决定,需要思考和测试。