I'm writing a command line application in Java. That app will scan a list of remote resources, do several attempts to access those resources, report failed attempts, and if succesfully accesed, perform some maintenance or diagnosis action and report the outcomes of that action.
As you can imagine, there's a lot of error handling and error reporting. But reporting the errors is a feature. Let me explain: a report with the errors encountered when attempting to access to the remote resource is something the user expects from the app, since those failures are useful for the diagnosis. Such access failures are expected in many cases and the causes should be reported.
As you can see, there's a blurry line between what's an error and what's the expected output of the app, which as every app will have its own errors also.
I'm using the Java Logging API and I'm designing my classes in a way as to be able to add different loggers and swap loggers and/or handlers (to screen, to file, to database, etc), as well as different list of resources to scan (and different types of those resources).
The problem is that I'm tempted to call logger.log()
everywhere I was previosly using System.put.println();
Right now I'm now in a position where there's a blury line between what should be printed with System.out.println()
and what should be send to the Logger
instance.
I believe I'm having a conceptual confusion.
So the questions are, given the fact that errors reporting is a part of the core functionality of the app and that, as any app, it has to handle and log its own errors:
- What things should be printed with
System.out.println()
- What things should be forwarded to a
Logger
- What things should be both printed with
System.out.println()
and forwarded to aLogger
- Should normal output be considered as being log messages of a low severity level or not at all?
EDIT:
Just to clarify, the app could attempt to download a file, but it's not the file what the final user wants, but to see whether or not it was accessible and if not, why. The resource could be a server, a database, a service or a file. The user doesn't want the app to get what the resource offers but to check availability and report the cause. That somehow makes failed attempts code errors the output users want to get from this app. Hence the thin line between logging or printing.