JBO Exceptions

Question

Hi there,
I'm fairly new to JDeveloper, and the Oracle Business Components, but after much playing around I've got them working nicely. We're using them inside a servlet, and we don't want the user names and passwords hardcoded into the app. Not a problem, we can just substitute variables into the Transaction.connect(String URL) method call. This all works great, unless you specify an incorrect username and password, in which case an unadvertised oracle.jbo.DMLException is thrown.
My concern is that I was under the impression that Exceptions must be declared as 'thrown' by the method signature in order for the class to even compile. Given that this clearly isn't the case, what other undocumented Exceptions could be thrown by the Business Components that we don't find until we go live? Is there somewhere I can find out? And why did Oracle decide not to include these in the 'throws' clause of the method signature?
Regards,
Steve.
null

Answer 1

More Info from our Developers...
Java supports two different kinds of exceptions:
static exceptions and runtime exceptions.
Static exceptions must be declared on the method declaration. As you
know, code calling a method with static exceptions must either catch
the exceptions or declare itself to throw the same or superclass exceptions.
With runtime exceptions, they don't have to be declared on the method.
Most 'famous' of these runtime exceptions are
NullPointerException, ArrayIndexOutOfBoundsException,
ClassCastException.
Static exceptions, as the phrase suggests, are good for methods whose
call chains are relatively static. If A calls B, and B calls C, and
if this chain of calls does not change in arbitrary manner, exceptions thrown by C can be statically declared, forcing B to
either handle or pass the exceptions.
As you mentioned, what's nice about static exceptions is that it
allows compile-time checking.
Static exceptions are not necessarily appropriate all the time. If
static exceptions were always appropriate, Java would not have
bothered with runtime exceptions. If you think about
NullPointerException, you will see why it wouldn't make sense to make
it a static exception. NullPointerException can be thrown by any
piece of Java code. If NullPointerException were a static exception,
all methods would have to either (1) have catch block almost
everywhere to handle NullPointerException, or (2) declare to throw NullPointerException.
The reason why NullPointerException wouldn't make a good static
exception is because it is ubiquitous. It can be thrown at unexpected places.
Another reason for not making an exception static would be if code
can easily be inserted in an overriding method (of a subclass) and
cause that exception to be thrown. Let's take an example.
Suppose
ArrayOutOfIndexException were a static exception.
Suppose I have the following method in the base class:
public class BaseClass
void myMethod()
System.out.println("hello");
Now, suppose I build a subclass on BaseClass and override
myMethod,
as in:
public class SubClass extends BaseClass
void myMethod()
Further, I have some code in the body of SubClass.myMethod that deals
with an array object, say
void myMethod()
int iArr = new int[2];
// This line will throw ArrayIndexOutOfBoundsException
iArr[3] = 0;
If ArrayIndexOutOfBoundsException were static, all of a sudden,
SubClass.myMethod would have to declare that it throws ArrayIndexOutOfBoundsException. However, since the base
implementation myMethod did not mention any exception on its
declaration, we can't put "throws
ArrayIndexOutOfBoundsException" in
the subclass implementation (Java doesn't allow this). The only
thing SubClass.myMethod can do is either (1) catch ArrayIndexOutOfBoundsException and eat it or (2) wrap it in
a runtime
exception and throw the runtime exception.
=====
The main reason why we (BC4J) decided to use runtime exceptions
and not static exceptions is for the two reasons that I described
above: ubiquitous-ness of some exceptions and
overriddability of methods.
One of the big benefits of BC4J is tier-independent programming where
the same piece of code can run in local mode or 3 tier (networked)
mode. When running in 3 tier, any method can make a trip to middle
tier server. This means (among other things) network failure or
server failure can occur practically anywhere. If these exceptions
were static, most BC4J methods would have to declare them on their methods.
Also, BC4J has 'deferred' mode where data changes can be deferred
and batched up on the client before they are sent to middle tier.
Thus, method calls like setAttribute() can be batched and later sent
to middle tier when something like createViewObject() is called. If
BC4J exceptions were static, all possible exceptions that can be
thrown by setAttribute, e.g., ValidationException, can be thrown by
createViewObject because the setAttribute call was deferred. This
will not only confuse the user (why should caller of createViewObject
worry about validation failure?), but it will cause ubiquitous and
often unnecessary declaring and handling of exceptions.
Let's talk about the overriddability issue. One of BC4J's big
benefits is customizability. The user can add their custom code and
subclass and override methods at practically anywhere in the system.
This makes management of exceptions quite cumbersome if they were
static. For example, at first it may seem obvious that getAttribute() should never throw ValidationException, since
it is unlikely getAttribute will change data.
However, it is quite reasonable for getAttribute() to call
setAttribute() for other calculated-but-cached-transiently data. For
this situation, this overridden getAttribute now needs to throw
ValidationException.
This kind of arbitrary call chaining and customization means that we
end up making most methods throw the most base class BC4J exception,
namely JboException. To have all our methods declared to throw
JboException would be meaningless, in much the same way as it would
be meaningless for methods to be declared with 'throws Exception'.
=====
The official and best way to find out which exceptions that a method
is known to throw would be the method's Java-doc. It's true that
the list at the moment may not be complete at the moment, but Java-doc
is the best place to start.
Also, when you get an exception, take a look at the Java-doc for the
exception class itself to figure out why it's thrown.
I Hope this helps.
John- JDeveloper Team
null