2

In Java, exception handling can be done in multiple ways. Let's differentiate exception handling using Logging framework as log4j or sl4j, where both of these could either redirect the logs to a file in addition to handle the exception.

If, instead of Logger framework, we use exception class method printStackTrace() to handle the exception and to get the exception call stack by redirecting it to a file rather than to standard error output/console, now, following are the questions:

  1. Would the later implementation handle the exception at all OR will simply print the exception to file?
  2. On what grounds does implementing Logger framework is prefered over printStacktrace() in Production environment?

Thanks in advance!

diogo
  • 3,769
  • 1
  • 24
  • 30
Akhil Gupta
  • 265
  • 1
  • 14
  • I usually see both being used actually. I have seen `log4j` and `sl4j` used and when an exception is caught, the output from `printStacktrace()` is sent to the logger. – Tim Biegeleisen Nov 23 '16 at 15:33
  • Thanks Tim, but was wondering which option to go for in production, since we can have appenders and rotation available to be achieved using configuration is the only thing that makes it more favorable over printstacktrace() – Akhil Gupta Nov 23 '16 at 15:36
  • What do you mean with "later implementation" in the first question? – Niklas P Nov 23 '16 at 15:45
  • It's like comparing saving things to a file vs. using a database. If you're only doing *very* simple things, you might not see a difference. Same applies here. – Kayaman Nov 23 '16 at 15:48
  • @Niklas by later I intended to say if we use printStackTrace() against using a logger framework – Akhil Gupta Nov 23 '16 at 16:06
  • You do know that Java has [its own logging framework](http://docs.oracle.com/javase/8/docs/api/java/util/logging/package-summary.html), right? And Java 9 will have an even simpler logging framework, accessible through the [System.getLogger](http://download.java.net/java/jigsaw/docs/api/java/lang/System.html#getLogger-java.lang.String-) method. – VGR Nov 23 '16 at 16:12
  • Possible duplicate of [Avoid printStackTrace(); use a logger call instead](https://stackoverflow.com/questions/10477607/avoid-printstacktrace-use-a-logger-call-instead) – MT0 Jun 13 '17 at 13:54

2 Answers2

1

There are a lot of reasons why you shouldn't use printStackTrace() and, once it's not a recent thing here, let's not reivent the wheel (special attention for the God's Perfect Exception link, very good one indeed).

Logging frameworks allow us many things (so many):

  • Send our logs to different places at the same time. Most of them come with several appenders that do things like console and file output and send logging messages using email or JMS, e.g.;
  • Customize messages with severity levels, origin, filter keyring, etc;
  • Easy and custom configuration based in xml/properties files, without needing to change Java code;
  • Good async handling, mainly for distributed systems;
  • Verbosity configuration, setting the way your exceptions will be logged;
  • etc.

The custom appender feature, specially, is great because we can send logs to non-file destinations, like Splunk, Sumo Logic, Loggly, logstash, etc. just as many companies already do nowadays to analyse and monitor their production systems.

Plus, consider analysing the right logging framework for your needs.

Community
  • 1
  • 1
diogo
  • 3,769
  • 1
  • 24
  • 30
0

To 2) The logging frameworks aren't better file handler but, for example, extract the configuration of the logging out of the code. So when you change the configuration (e.g. other detail level of logs for development and production) you don't have to change the code - you just use other logging framework configurations for each test stage. If you want to change the log file names, the log file size (rotation) or the specific log detail of different packages or classes, you can easily do that by modifying the configuration.

Niklas P
  • 3,427
  • 2
  • 15
  • 19
  • Thanks Niklas I guess logger can be compared with printStackTrace() in terms of printing the log messages but not in term of exception handling as none of these do exception handling but simple loggs to different file/streams.... I am correct? – Akhil Gupta Nov 23 '16 at 16:10
  • I am not sure what you mean with "exception handling". I personally use the term "exception handling" when I implement the business logic what to do when an exception occurs - abort the business logic/transaction and display a specific error, abort the business logic/transaction and display a standard error and log the details, finish the business logic/transaction and in the background log the details, ... - all these decisions can NOT be done by logging framework. So in my words I would say that a logging framework can NOT do the exception handling. – Niklas P Nov 24 '16 at 08:37