User side errors added

[mk868]

In these changes I added new exceptions that can be thrown from the user implementation level. An example use case:

public class SimpleObject implements Properties, HalModule 

  // ...

  @Override
  public <A> void Set(String interface_name, String property_name, A value) {
    if (/* interface does not exist */) {
      throw new UnknownInterface("Interface " + interface_name + " not found");
    }
    if (/* property does not exist */) {
      throw new UnknownProperty("Property " + property_name + " not found in " + interface_name);
    }
    if (/* property read-only */) {
      throw new PropertyReadOnly("Property " + property_name + " readonly");
    }
    // do update stuff
  }

  // ...

}

Additionally I removed redundant @SuppressWarnings("serial") error annotations.

[hypfvieh]

Removing the @SuppressWarnings("serial") will create warning because of missing serial (because Throwable implements Serializable). I changed your PR to include serials for the exceptions. I also changed the InvalidArgs exception to InvalidMethodArgument to clarify the purpose of this exception.

[mk868]

Thank you,

For the error name InvalidMethodArgument, we should make sure it is mapped correctly from/to org.freedesktop.DBus.Error.InvalidArgs error type. I used naming convention from DBusBindingErrors (I only added those useful from the user's point of view).

[hypfvieh]

I don't think that the exception names are predefined. For me the referenced document looks like an unfinished discussion. At the end of the document there is the question if the list of exceptions is complete and that this list only reflections the errors known in glib bindings (back in 2013). Also the note about the order (because glib use enum for it) is just a side note which does not matter for Java exceptions.

The only words the specification of DBus contain about exceptions is, that when DBus sends an Error signal that this should be mapped to exceptions if the used programming language supports exceptions.

Quote of Specs:

Error replies are normally mapped to exceptions in languages that have exceptions.

The names for exceptions on the 'client side' are suggestions by some folks trying to use the same name of exceptions in different programming languages. As you have to take care of checked exceptions in Java anyhow, it should be no problem to use other names as well. The exception itself will never be serialized and send through DBus so it is only seen on the caller side (the Java program).