EtcdException to have constructor accepting string value about etcd4j HOT 6 CLOSED

I dont't think that would be a good idea:

1. The EtcdException is directly representing an error response of etcd, see it's public fields, and where it is instantiated. I guess it was on purpose that the default constructor was overwritten, so that you can't use the other constructors of Exception.
2. Even when the first point would not be there: I would prefer a more generic or a self created exception, which is related to your usecase. For example: if you use etcd for storing configuration data, then throw e.g. your own ConfigurationException. If you don't like to have your own exceptions, throw e.g. an IOException (because reading and writing configuration data is an I/O operation). This way the other parts of your application don't need to know anything about etcd and etcd4j, which is cleaner imho.

Just my 2 cents :)

from etcd4j.

Well I think I might agree on the ConfigurationException. Btw is there a way to communicate without spamming here?

from etcd4j.

At least I don't know another way to communicate...

from etcd4j.

Communicating through issues is I think the way Github works. It forces you to think which issues are open so it focusses on action. So you are welcome to open any questions/issues you encounter. If the project grows so big that user questions/issues in one store are too confusing I would probably add a link in the README for a new recommended place.

I agree with @slintes. EtcdExceptions should only be thrown by etcd itself so it keeps true to its original format and purpose. If you want to handle the exceptions on multiple places in your own code it is best to wrap the exceptions in your own defined exception. This way it is also easier to replace etcd4j with something different if something better comes up or if etcd4j changes the way exceptions work it is easier for you to adapt.

@ghristov It is also possible to "pipe" multiple types of exceptions to one catch block.

try{
    promise.get();
} catch (IOException | EtcdException | TimeoutException e) {
    LOGGER.warn(e.getMessage());
}

But one thing that I didn't do and could possibly do is letting EtcdException extend IOException. It would save 1 catch in a generic try catch handler. But it would make EtcdException a bit more hidden so you need to add it manually to a catch block. What are your thoughts?

from etcd4j.

Ok agreed that EtcdException is ok like this. Actually I capture EtcdException,IOException, TimeoutException and throw ConfigurationException.

Regarding extending IOException... I think now is better. Like you said already, extending it you will hide information. Leave it that way. I will close this issue.

from etcd4j.

👍

from etcd4j.