Exception.getMessage（）为null

时间：2011-11-23 03:52:06

标签： java exception

在我的Java代码中，它正在检查!null条件并抛出Exception。

例如

try
{
    if (stud.getCall() != null)
        acc.Call = stud.getCall().toString();
    else
        throw new Exception("Data is null");
}
catch (Exception e)
{
    logger.error("Some Error" + e.getMessage());
    throw new Exception("Please check the Manatadatory Field is Missing" + e.getMessage());
}

但是在我得到的日志中：

Some Error null

为什么e.getMessage null？

9 个答案:

答案 0 :(得分：43)

您正在捕获除代码明确创建并抛出 1 之外的异常。您捕获的例外没有消息。您需要记录整个异常，而不仅仅是异常消息。 （除其他外，它会告诉你捕获的异常的实际类是什么以及创建/抛出异常的位置。）

基于异常没有消息的事实，我猜它是由stud或acc为空或由stud.getCall()返回导致的NPE null ......或类似的东西。本地生成的NullPointerException（即由JVM）生成null消息 2 。

投掷java.lang.Exception是不良做法

您的问题说明了为什么创建/抛出Exception

通常是个坏主意

当您抛出Exception时，几乎无法区分它与catch子句中的其他（意外）异常。这就是这里发生的事情：你已经发现了错误的异常。

您应该选择一个更具体的例外，如果不存在合适的例外，请实施您自己的例外。

1 - 您还可以使用e.printStackTrace()，记录器调用或调试器来查找实际捕获的异常。

2 - 在Android上不是这样。在那里，NPE有一条有用的信息，可以提供上下文信息。

答案 1 :(得分：16)

尝试打印异常，而不仅仅是消息，例如

logger.error("caught exception while doing whatever", e);

看看它的作用。只打印消息是一个混乱的秘诀。通过仅记录您丢弃堆栈跟踪的消息，其中行号指向导致异常的位置。现在你发现并非所有例外都包含一条消息。

抛出新异常是非常糟糕的，因为你丢弃了异常的原始类型，加上原始异常的堆栈跟踪。当你扔掉所有有用的信息时，你怎么能指出出了什么问题呢？如果你必须捕获异常以在此处记录它，那么重新抛出你捕获的同一异常，至少这样你就不会丢失堆栈跟踪。 （或者，您可以在构造函数调用中传入对原始异常的引用时抛出一个新异常。）

最好使用集中式异常处理程序，让它执行日志记录，并在意外异常处理之前不会被捕获。因为一旦某个东西抛出了意外的异常，你的应用程序处于错误的状态，任何依赖于这部分应该做的事情的后续步骤都会失败，并且你会得到一连串的错误。

答案 2 :(得分：10)

这是我修复同样问题的方法，使用它来查看异常：

"" + e);

当原始程序员抛出Exception对象而不实现.getMessage();

时，这将对您有所帮助

我责怪Google允许使用null getMessage();

的Exception对象

当我的代码获得java.lang.NullPointerException时 随后导致我的异常日志记录在e.getMessage();

上失败

来自null的{​​{1}}导致了另一个未处理的异常，并使用强制关闭消息崩溃了应用程序。 所以就是这样：

.getMessage();

我将其更改为此更正版本：

Log.e("MainLogger.Run.Exception", e.getMessage());

现在它给了我一个很好的字符串返回Log.e("MainLogger.Run.Exception", "" + e);

答案 3 :(得分：1)

派对迟到了，但我敢打赌stud为空，你得到的例外是NullPointerException if (stud.getCall()....。它是没有消息的例外之一，即null。

答案 4 :(得分：0)

代码看起来语法很好，e.getMessage（）不应该为null，我编译相同的代码并在控制台上打印输出，它打印为"Some ErrorData is null"，这很好。现在，您的记录器存在问题，或者您可能正在查看记录器文件中的错误行。

  

logger的问题可能是什么

这完全取决于您使用的记录器？你有没有重写looger.error（）的方法？但是可以肯定的是，catch块中的e.getMessage（）不为null。您也可以通过在catch块中的控制台上打印e.geMes​​sage（）来尝试。

答案 5 :(得分：0)

在调用getMessage（）之前调用printStackTrace（）。这个方法

  

将此Throwable的堆栈跟踪的可打印表示写入   System.err流。

try
{
    if (stud.getCall() != null)
        acc.Call = stud.getCall().toString();
    else
        throw new Exception("Data is null");
}
catch (Exception e)
{
    e.printStackTrace();
    logger.error("Some Error" + e.getMessage());
    throw new Exception("Please check the Manatadatory Field is Missing" + e.getMessage());
}

答案 6 :(得分：0)

我希望这对你有帮助....

如果要打印消息“Data is null”，则不要使用Build-in类“Exception”，而是尝试使用您编写此代码的类的名称。 例如： 如果类名是“DemoClass”（你编写这段代码的类），那么这样写：

 try{
if (stud.getCall() != null)
    acc.Call = stud.getCall().toString();
else
    throw new DemoClass("Data is null");
}
catch (DemoClass e){
logger.error("Some Error" + e.getMessage());}

如果你要重新投掷，那么不要忘记在你的函数一边提出“抛出DemoClass”（编写这段代码的地方）：

 throw new DemoClass("Please check the Mandatory Field is Missing" + e.getMessage());

答案 7 :(得分：0)

想评论hamish的"" + e答案，但我的信誉度不足...

最好只使用e.toString()而不是"" + e。结果是相同的，但在内部，后者可能会进行不必要的串联操作，包括创建StringBuilder，附加空白字符串，附加e.toString（）结果然后转换回String。有关在幕后使用StringBuilder的详细信息，请参见https://www.baeldung.com/java-strings-concatenation的“ 3.加法运算符”。

关于最初的问题，我建议使用e.getString（）（或者更好的方法是执行完整的堆栈跟踪），而不是仅仅使用e.getMessage（）。对于某些异常，如果不知道异常类型，则该消息是没有意义的。我遇到的一个示例是e.getMessage（）返回“ -1”，而e.toString（）返回“ ArrayIndexOutOfBoundsException：-1”。您希望在日志中看到哪个？ ：-）

答案 8 :(得分：0)

在我的情况下，它返回带有空消息的错误Exception，因为我将方法调用的结果包装在Optional变量中：

这是对MongoRepository数据库操作的调用：

 Optional<CustomerDB> result = Optional.of(repository.findByToken(token));

函数“ repository.findByToken（token）”只是返回一个CustomerDB对象。

我将代码行更改为：

CustomerDB result = repository.findByToken(token);

我得到了正确的消息例外。

相关问题
最新问题