David Blevins wrote:
Correct. Should it throw SQLExceptions which in my opinion are of no
value to a client? I think the bean itself should catch it and throw
your own designed application exception, but...
We're not exactly talking about "a client" as in clients in general.
The test suite client creates and drops the required tables in the
JUnit setup and tearDown methods via an ejb that accepts SQL
statements and throws SQLException. This is fine for out test suite
app.
That's not necessarily true. The client is the JUnit app in this case.
It's a remote client that looks up beans and invokes their ops. So, I
don't agree it's not a client. It's a client as others.
I guess I'm not sure how to implement that. How do we know in advance
what exceptions are of no value to the client?
That's what I was asking about. The bean provider should decide which
exceptions are of any value to a client and I don't see any value in
exceptions being sent back to the client. What exactly would the client
do? The only thing I can think of is to report it, i.e. printing it out
to the console. It leads to my question. Since we're the bean provider I
wonder what the reason was to (attempt to) send SQLExceptions back to
its client, i.e. the JUnit script?
Also, since all
exceptions implement serializable, we don't know a particular
exception instance isn't serializable till we try and serialize it
and it fails.
Well, what about the java.io.Serializable interface? Isn't it all we
want to find out whether a class is serializable or not?
That's however another story. The real question refers to the bean that
throws SQLException and I don't understand why we[*] have decided to do so?
[*] I've included myself to be polite ;)
-David
Jacek
