Archived
This forum has been archived. Please start a new discussion on GitHub.
Mapping Exception
Hi,
it would be nice to have the possibility to specify exceptions that
represent general runtime errors at object implementation level that,
in Java, would be derived from java.lang.RuntimeException.
Consider the following:
module sample {
// marked somehow to derive from
// java.lang.RuntimeException, unchecked keyword ??
exception SystemError {
string message;
}
exception OutOfMemoryError extends SystemError {
}
interface RemoteService {
void doSomething(); // no throws clause for SystemError
}
}
Two benefits: first you don't have the add "throw SystemError" to all
the operations of an interface; second, the client is not aware of
implementation details in the normal case (it is aware only of
"logic" errors).
Regards,
Guido.
it would be nice to have the possibility to specify exceptions that
represent general runtime errors at object implementation level that,
in Java, would be derived from java.lang.RuntimeException.
Consider the following:
module sample {
// marked somehow to derive from
// java.lang.RuntimeException, unchecked keyword ??
exception SystemError {
string message;
}
exception OutOfMemoryError extends SystemError {
}
interface RemoteService {
void doSomething(); // no throws clause for SystemError
}
}
Two benefits: first you don't have the add "throw SystemError" to all
the operations of an interface; second, the client is not aware of
implementation details in the normal case (it is aware only of
"logic" errors).
Regards,
Guido.
0
Comments
-
Hi,
I'm also interested by this.
We have a lot of slices already defined without exception (ok, that's bad). Actually, clients catch UnknownException (ok, that's worst).
I would like to introduce a new exception hierarchy without modifying the slices, by throwing RuntimeException.
Is it possible?0 -
No, this is not possible. Ice has to know about the exceptions that can be raised (i.e., exceptions must be defined in Slice), otherwise it cannot know how to marshal them.
We might add the option for the user to define runtime exceptions in a future version of Ice, but these would have to be defined in Slice as well. The only difference to user exceptions would be that these are "unchecked" exceptions, i.e., they would not have to appear in the throws clause of operations. (Note that this would be a very intrusive change to Ice, so while it is on our todo list, don't expect this anytime soon.)
Having said this, I don't think such runtime exceptions should be used where user exceptions (exceptions listed in the throws clause of operations) are more appropriate.0 -
Hi guys,
I have been pondering this too. A lot of java libraries nowadays rely simply on unchecked exceptions, and this is certainly my preference.
That said, there appear to be 2 "simple" ways to achieve this:
* Have an alternate Java mapping where Ice.UserException derives from RuntimeException instead of Exception.
* Use Slice metadata to indicate which Slice exceptions are unchecked (defaulting to checked exceptions). In the Java mapping, have Ice.UserException (as with the current situation) for standard exceptions, and a new exception hierarchy based on Ice.UncheckedUserException (derived from RuntimeException) for the unchecked ones.
Any thoughts?0 -
Hi Gary,
At the Slice level, user exceptions must remain "checked" (explicitly listed by operations that raise them), because slice2java (slice2cpp etc.) generates code to handle them.
At the Java level, we could indeed provide metadata to allow you to map your user exceptions to Runtime exceptions (your second option). Your first option - an alternate mapping, with its separate Ice.jar file - sounds a bit excessive.
Best regards,
Bernard0
