How to organize the output of the error message in the Java program?

Good day, Habr!

There was such question: how to respond to improper arguments at the entrance?

The situation is this:

write zapuskalku for one web server. By design it can run in two modes:

1) In embedded mode (when its configure in main application)

2) In standalone mode (then pass parameters via the command line)

Now made so:

All the arguments validinputs in one place (in the setters of the object configuration) and if the parameter is critical (for example, the port on which the server starts), then on the outside an exception is thrown.

The situation is compounded by the fact that validation occurs in the constructor, it turns out that even the constructor throws an exception (to put it mildly that should not be, judging from the advice in the book "code complete").
October 3rd 19 at 02:49
2 answers
October 3rd 19 at 02:51
Doing the right thing. Only if you have the app from the console runs, I would suggest to use Commons CLI for parsing the input arguments.
Don't see the problem of validation in the constructor (for example), but if you really want to change — enter a static factory method to which pomestite all the validation, and make the constructor private.

I probably would have done so: Input in the form of a Commons CLI Options, then convert it into a class structure setup (regardless of CLI, in the case of embedded mode and filling of this structure) without validation, a static factory method with this setting, where all the validation and setting of parameters of the business object.
October 3rd 19 at 02:53
"I usually write" (C)

1. In the constructor for all the configuration parameters to default values
2. By any means — of environment variables, command line arguments, configuration files, etc. trying to clarify our configuration
3. Create a validate () method — only in this test the configuration for validity and only in him write errors associated with this
4. Run the main program branch

In the pseudocode it looks like this
service = new TService();

And in the book all is correctly written — no exceptions in constructors!
no exceptions in constructors

Why is that? Just let us constructively, that is, for example, counter-reflections. - cathrine commented on October 3rd 19 at 02:56
Thanks for the idea.
A small clarification:

How to protect code from this:

service = new TService();
service.doJob(); //Then at this stage may be erroneous data. - Patricia commented on October 3rd 19 at 02:59
And why do you loadConfig() separated it validateConfig(), what will happen if someone forget to call the second method?
In fact, a situation will arise that sushestvuet instance of the service is not configured (for example, validateConfig called but threw an exception) - cathrine commented on October 3rd 19 at 03:02
Here a man writes:

One thing to be careful of about throwing exceptions in the constructor: because the caller (usually) will have no way of using the new object, the constructor ought to be careful to avoid acquiring unmanaged resources (file handles etc) and then throwing an exception without releasing them. For example, if the constructor tries to open a FileInputStream and a FileOutputStream, and the first succeeds but the second fails, you should try to close the first stream. This becomes harder if it's a subclass constructor which throws the exception, of course... it all becomes a bit tricky. It's not a problem very often, but it's worth considering.

my practical experience confirms — the exception in the constructor is the path to the elusive problems and errors

And why do you loadConfig() separated it validateConfig()

1. For purposes of illustration, it can be placed at the end of loadConfig()
2. validateConfig you can call at any time, without calling loadConfig during runtime. This is simply on the machine I have every datvie execute in a separate function — debajit and easier to read code - Kian26 commented on October 3rd 19 at 03:05

Find more questions by tags JavaProgramming