Dursun Koç

you are right, as we already discussed with @Cayo Souza, and @Ivan Karamazov, Optional would be a better solution. Besides I do not think that the solution without Optional is a terrible one.

Thanks for your comment :).

Firstly, I am not a person who hates exceptions. I think when there is an exceptional case we should use exception, but we should not use exception for control flow, otherwise, the exception becomes like the goto keyword.

When it comes to readability, every function should have one kind of return type, but if we use exception (regardless checked or not), our function will have more than one return type, either an exception or a data type. Besides I agree with your comment about using checked exceptions over unchecked ones.

I see you, you mean the `findUserNoEx` method is problematic. how about this one, or do you have something else in your mind?

private static String findUserNoEx(String name) {
return name == null ? "" : name;
}

As stated in the article, if it is an exceptional case then use exception, if it is not, then check your design.

returning null would cause another null check on the client. Think "" as a default value. Afterall I think "Optional" would be a better solution.

sorry for late response:

here you can find a sample project

https://github.com/dursunkoc/samplespringbootdbconfigserver

Thanks for your advices, I have just edited sample codes for indentation.

I think i missed to mention that my OS is windows and RR is not the default scheduling policy.

This article is a gentle introduction, so I did not mention about the setupMaster. Maybe in a detailed article we can discuss setupMaster as well.

on the clientside you don't need to care about the failover, besides on the serverside if any of the child process dies, then the cluster module will forward requests to the existing ones; also it will emit the 'exit' event, so you can catch up this event re-start the died process again, watch the following code.

cluster.on('exit', function(worker, code, signal) { console.log('worker %d died (%s). restarting...', worker.process.pid, signal || code); cluster.fork(); });