How does Log.wtf() differ from Log.e()?
AndroidAndroid Problem Overview
I have looked at the documentation for android.util.Log and I'm not sure exactly what the difference between Log.e()
and Log.wtf()
is. Is one preferred over the other? Is there a functionality difference? Surely they aren't redundant.
Note to future readers: At the time this question was asked, the documentation for this was much less clear. If you follow the link above, they have fixed the problem.
Android Solutions
Solution 1 - Android
There is a difference in severity;
Log.e()
will simply log an error to the log with priority ERROR.
Log.wtf()
will log an error with priority level ASSERT, and may (depending on the system configuration) send an error report and terminate the program immediately.
Solution 2 - Android
COMMON MISTAKE
Official docs say:
Log.e()
logs with priority ERROR. However, Log.wtf()
logs with priority ASSERT.
ASSERT has priority constant = 7
ERROR has priority constant = 6
So Log.wtf()
has higher priority with respect to Log.e()
However source code conflicts with above information.
static int wtf(int logId, String tag, String msg, Throwable tr,boolean localStack, boolean system) {
TerribleFailure what = new TerribleFailure(msg, tr);
// Only mark this as ERROR, do not use ASSERT since that should be
// reserved for cases where the system is guaranteed to abort.
// The onTerribleFailure call does not always cause a crash.
int bytes = printlns(logId, ERROR, tag, msg, localStack ? what : tr);
...
}
It looks like there is a mistake in Official docs. Because both Log.wtf()
and Log.e()
logs with priority ERROR.
REAL DIFFERENCE
Source Code for Log.e():
public static int e(@Nullable String tag, @Nullable String msg,@Nullable Throwable tr) {
return printlns(LOG_ID_MAIN, ERROR, tag, msg, tr);
}
The difference is that Log.wtf() might call onTerribleFailure() call back.
onTerribleFailure() may or may not cause the process to terminate (depends on system settings).
TL;DR
Log.wtf() might call onTerribleFailure() and can cause termination of your application.
Solution 3 - Android
Log.e()
is the simply log an error to the log with priority as ERROR.
Log.wtf()
(What a terrible failure) is more severe than error log. The error which never ever ever, ever happened. It may force the device to hold for writing the logs before terminate the program.
Solution 4 - Android
Actually, this might be a documentation error in Android SDK, what a surprise... Doc says:
> The error will always be logged at level ASSERT with the call stack.
But source code says this:
static int wtf(int logId, String tag, String msg, Throwable tr, boolean localStack, boolean system) {
...
int bytes = printlns(logId, ERROR, tag, msg, localStack ? what : tr);
...
}
So, Log.wtf() and Log.e() both have the same priority, ERROR.
The difference is that Log.wtf() calls for onTerribleFailure() call back, which "Report a serious error in the current process. May or may not cause the process to terminate (depends on system settings)."
So, in other words, Log.wtf() could crash your app.
Below is a code snippet:
if (ActivityManager.getService().handleApplicationWtf(
mApplicationObject, tag, system,
new ApplicationErrorReport.ParcelableCrashInfo(t))) {
// The Activity Manager has already written us off -- now exit.
Process.killProcess(Process.myPid());
System.exit(10);
}
Solution 5 - Android
As with the other logging types, I understand it to be just another label type for log messages. log.i is for information about where something is occuring. log.e is for errors that could happen. log.wtf is for errors that never happen. I think it is just a convienience so you don't have something like Log("ERROR:", "an error") and Log("INFO: ", "information")
Solution 6 - Android
I think that wtf (what a terrible failure) is used to report serious exceptions/problems of your applications (e.g. report them in your debug console).
log.e is used to report errors, but no so serious.
Solution 7 - Android
I did not know this until I worked on the ROM layer.
Log.wtf() will terminate your process if certain conditions are set. I was quite confused as to why the system service was crashing all of the time. It was that I used Log.wtf() and it was getting fired off for something "that should never be happening"