3

I read here that e.printStackTrace() should not be used to catch exceptions on android.

On another source I read that I should use Log.e() instead of e.printStackTrace():

... catch (Exception e) {
 Log.e(TAG, "Foo did not work", e);
}

Do I have to manually remove these calls in the release build? What is the best practice to trace exception logs in Android?

Community
  • 1
  • 1
Mike76
  • 899
  • 1
  • 9
  • 31
  • where exactly did read that ? – Blackbelt Sep 29 '15 at 07:44
  • http://stackoverflow.com/questions/3855187/is-it-a-bad-idea-to-use-printstacktrace-in-android-exceptions – Mike76 Sep 29 '15 at 07:45
  • 2
    well instead of showing aStackTrace you log the actual error for further refference of your programms problems. Thats good :) – Tom Wellbrock Sep 29 '15 at 07:47
  • 1
    If you use e.printStackTrace the system will write all that info in the standar output, always is better to use loggers so you can redirect all the output to some file...and change what do you want to write in that file without touching the code. – David Herrero Sep 29 '15 at 07:48
  • it is still his opinion. I don't see any reason why it should be a bad idea. Btw e.printStackTrace() logs on the error level – Blackbelt Sep 29 '15 at 07:49
  • TThe Log.e() seems to print the stack trace with the third parameter – Mike76 Sep 29 '15 at 07:50
  • thats not only opinion based! the StackTrace only shows you the exceptions in your console. A log is saved and can be accsessed anytime, it also can be filtert wich provides a better view over what your programm does and how it handles its exceptions – Tom Wellbrock Sep 29 '15 at 07:51
  • Do I have to remove the Log.e() calls in the release build? – Mike76 Sep 29 '15 at 08:00
  • thats for you to decide. But I recommend to not delet them. For example you could store them in a file. If your user then gets a problem and wants to get support he can send you the error log wich helps you for debugging – Tom Wellbrock Sep 29 '15 at 08:02
  • So it seems that `e.printStackPrace()` is definitely inferior to `Log.e(tag, message, throwable)`? – Mike76 Sep 29 '15 at 08:13
  • 1
    e.printStackPrace() is inheritted from Java. Log.e() is more specific to Android, and it is definitely a more proper way of logging errors in Android. – Krypton Sep 29 '15 at 08:51

1 Answers1

2

The main intent of catching exceptions, is of course handling an occuring problem and due to this your catch part should always handle the error in some way e.g. use default values for the things which did not work, or try something different.

Anyway, if you are planning to publish your app in the Google Play Store and if you want to log the exceptions and use them for debugging puropses, to further improve app you can use Google Analytics API part for handling exceptions. It also provides facilities for collecting stack traces. (this is an exmaple from the API pages)

// Using StandardExceptionParser to get an Exception description.
try {

  // Request some scores from the network.
  ArrayList<Integer> highScores = getHighScoresFromCloud();

} catch (IOException e) {
// Get tracker.
Tracker t = ((AnalyticsSampleApp) getActivity().getApplication()).getTracker(
    TrackerName.APP_TRACKER);

  t.send(new HitBuilders.ExceptionBuilder()
      .setDescription(
          new StandardExceptionParser(this, null)
              .getDescription(Thread.currentThread().getName(), e))
      .setFatal(false)
      .build()
  );

  ... // Display alert to user that high scores are currently unavailable.
}

Afterwards all tracked stracktraces will be display in the Google Developer Console in the tap of you app.

Crashed and ANR' in the Google Developer Console (picture taken from the web)

You can also add an Listener for catching unhandled exceptions. So whenever an exceptions occours which you did not expect whis handler will be invoked.

Thread.setDefaultUncaughtExceptionHandler(new MyReportHelper());

Of course you should always try to catch and handle all exceptions which you know of, this handler is only for emergencies. For more details how an handler could look like see here.

Community
  • 1
  • 1
Westranger
  • 1,308
  • 19
  • 29