考虑创建一个扩展runtimeexception的异常。例如， public class BlamException extends RuntimeException ... （将其命名为“badconfigurationexception”之类有意义的名称）。
runtimeexception的“争议”大多只是一些傻瓜，声称程序可以从意外的无效状态中恢复，而这种情况通常（也许只是经常）不是这样。在缺少配置值的情况下，很可能没有好的默认值。
如果要允许默认值，那么为缺少的配置值实现一个默认值，并记录一条消息，说明“warning:configuration value blam is missing”之类的内容。使用默认值：kapow”。
100%不应使用选中的异常。选中的异常要求程序捕获并“处理”该异常。在您的例子中，“handle”部分是“阻止应用程序启动”，如果抛出runtimeexception，就会发生这种情况。

只有在极少数情况下，我才会从应用程序代码中抛出预定义的异常。通常我定义自己的例外，就像@edwin dalorzo建议的那样。这在应用程序的更高层提供了更细粒度的控制，以决定如何处理它。至少我要做的是有两种不同的类型，一种是致命的（即我不能在应用程序内部处理的故障）和可恢复的故障（即应用程序可以处理的故障）。示例：如果您的应用程序在没有该配置变量的情况下无法运行，那么让气泡上升到应用程序的外层（即web应用程序或web服务中的控制器）是一种致命的情况。如果某个更高的层可以在没有该变量的情况下工作，那么这并不是致命的。主要区别在于：应用程序本身应该处理它还是只处理最外层？

怎么样 NoSuchElementException :
由各种访问器方法引发，以指示所请求的元素不存在。

我有一个方法，它首先在环境中搜索变量，如果在那里找不到它，它就会搜索config.properties。如果两者都不产生结果
这听起来不是很适合定义你自己吗 Exception ? 让我们来看一个情况：
你正在为银行开发一个应用程序，你想验证用户是否说 A 谁想给另一个用户汇款 B 所以在转帐之前，我们要检查一下 A 有那么多钱，如果他/她有，我们将结转这笔交易。
是什么 A 没有那么多的平衡？作为负责任的开发人员，您将通知 A . 这里有很多方法来处理它。但我更愿意在这里定义我自己的例外。 InsufficentBalanceException(int amount) .

您可以通过编写一个 Package 类来使用checked异常，如果您正在处理资源，这个 Package 类将用一个自定义消息扩展runtimeexception类。
总的来说，您需要将异常传播到应用程序级别，因为在启动应用程序时，配置确实很重要。
例子
错误类.java

public type doSomething(){
...
...
try{
   ...
} catch(FileNotFoundException e){
throw new MyCustomFileNotFoundException("config file not found", e); // no destructive wrapping here
}
}

mycustomfilenotfoundexception.java文件

public class MyCustomFileNotFoundException extends RuntimeException{
    public MyCustomFileNotFoundException(String msg, Throwable cause){
    super(msg, cause);
    }
}