t; EJBQL Query with relational queries (<, <=, >, >=) are throwing exceptions
> --
>
> Key: CAY-919
> URL: https://issues.apache.org/cayenne/browse/CAY-919
>
Just my 2 cents, perhaps I can pose this question in the users mailing list.
Thanks
Garry
> EJBQL Query with relational queries (<, <=, >, >=) are throwing exceptions
> --
>
>
e. Let me know if I
should create a new issue about the aliasing.
Thanks
Garry
> EJBQL Query with relational queries (<, <=, >, >=) are throwing exceptions
> --
>
> Key: CA
L Query with relational queries (<, <=, >, >=) are throwing exceptions
> --
>
> Key: CAY-919
> URL: https://issues.apache.org/cayenne/browse/CAY-919
> Project: Cayen
EJBQL Query with relational queries (<, <=, >, >=) are throwing exceptions
--
Key: CAY-919
URL: https://issues.apache.org/cayenne/browse/CAY-919
Project: Cayenne
I much prefer IllegalArguementException if it is an invalid method
parameter or IllegalStateException if the object is in an invalid
state for an method call.
The reason I dont throw NPE is because the JRE will do that. When I
see a NPE I generally think there may be a problem with the underlying
On 04/08/2007, at 2:41 AM, Mike Kienenberger wrote:
For what it's worth, when I write my own code these days, I use either
NullPointerException("variable-name") or IllegalArgumentException("why
it's illegal")
I also use IllegalArgumentException quite a bit in my own code. And I
think it mak
On Aug 3, 2007, at 7:55 PM, Kevin Menard wrote:
Then I suppose this would raise another topic. JUnit 3 is a bit of a
boar for testing exception. You basically have to try, catch, fail.
TestNG has a standard facility for testing for expected
exceptions. My
guess is that JUnit4 does as
> -Original Message-
> From: Andrus Adamchik [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 03, 2007 12:38 PM
> To: dev@cayenne.apache.org
> Subject: Re: Exceptions . . .
> For things like argument checking in the user-facing API,
> IllegalArgumentException seems
vin Menard wrote:
>
> > I imagine throwing
> > CayenneException is preferred, but given that it's a checked
> > exception,
> > that could mean rewriting interfaces.
>
> We certainly DO NOT want every method in Cayenne to throw checked
> exceptions. Then it will be as
On Aug 3, 2007, at 7:18 PM, Kevin Menard wrote:
I imagine throwing
CayenneException is preferred, but given that it's a checked
exception,
that could mean rewriting interfaces.
We certainly DO NOT want every method in Cayenne to throw checked
exceptions. Then it will be as "
> > From: Mike Kienenberger [mailto:[EMAIL PROTECTED]
> > Sent: Friday, August 03, 2007 12:07 PM
> > To: dev@cayenne.apache.org
> > Subject: Re: Exceptions . . .
> >
> > Yes, I'm not saying we do it right. I'm just saying we correct things
> > as w
> -Original Message-
> From: Mike Kienenberger [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 03, 2007 12:07 PM
> To: dev@cayenne.apache.org
> Subject: Re: Exceptions . . .
>
> Yes, I'm not saying we do it right. I'm just saying we correct things
> as
e.org
Subject: Re: Exceptions . . .
In my opinion, it's best to trap the error as soon as possible. As
far as I remember, that's our standard practice, and as we come
across
items like this, we correct them.
I may be mistaken, but my experience tracking down some problems in
the
p
ECTED]> wrote:
> > -Original Message-
> > From: Mike Kienenberger [mailto:[EMAIL PROTECTED]
> > Sent: Friday, August 03, 2007 11:59 AM
> > To: dev@cayenne.apache.org
> > Subject: Re: Exceptions . . .
> >
> > In my opinion, it's best to trap the er
+1
I don't think there's any disagreement on that.
Andrus
On Aug 3, 2007, at 6:58 PM, Mike Kienenberger wrote:
In my opinion, it's best to trap the error as soon as possible. As
far as I remember, that's our standard practice, and as we come across
items like this, we correct them.
On 8/3/
In my opinion, it's best to trap the error as soon as possible. As
far as I remember, that's our standard practice, and as we come across
items like this, we correct them.
On 8/3/07, Kevin Menard <[EMAIL PROTECTED]> wrote:
> I know this has come up before and some debate goes on and then no
> d
> -Original Message-
> From: Mike Kienenberger [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 03, 2007 11:59 AM
> To: dev@cayenne.apache.org
> Subject: Re: Exceptions . . .
>
> In my opinion, it's best to trap the error as soon as possible. As
> far as I
I know this has come up before and some debate goes on and then no
decision is really made. Do we want to improve exception reporting?
I've always found this to be a weak point in Cayenne's game.
Fortunately, I've become more comfortable with loading up the source
code and stepping through things
On Jul 16, 2007, at 8:16 AM, Marek Wawrzyczny wrote:
Could another option be to provide server side hooks at the point
where a CRE
is propagated to the client which allows the programmer to report the
exception server side?
This way, an exception can be send to the client as it is being
sen
ople who don't use Hessian. The nice thing is that
> > we can get real exception data onto the client which can be very
> > useful.
>
> While I don't think it will be always safe to rely on all drivers to
> provide fully serializable exceptions, I thought of another, m
ption data onto the client which can be very
useful.
While I don't think it will be always safe to rely on all drivers to
provide fully serializable exceptions, I thought of another, more
important reason why it won't work - client may not (and should not)
have all server classes
by BaseRemoteService at around line 175.
I need to improve upon my recent commit in order to properly deal
with non-serializable exceptions. Andrus has alerted me to the fact
that there are exceptions out there (such as one in Derby) which
implement Serializable but which have fields which
As I've mentioned offline, I think that if an exception message is
set by the user, it may be a bad idea to clobber it
Yep. Sorry for my brain lapse before - I know what you mean now. By
"clobber" you mean that ideally we shouldn't be touching the message
at all, even to append text to the e
Hi Ari,
As I've mentioned offline, I think that if an exception message is
set by the user, it may be a bad idea to clobber it
(CayenneRuntimeException 'getMessage()' kind of does it too, doh!).
The good news is that Cayenne internally uses a constructor without a
message: "ValidationExc
Validation exception messages in three tier are pretty unhelpful by
the time they get to the client. We've been extending them by adding
this to ValidationException:
/**
* Returns message that includes the details of the validation
failures.
*/
public String getMessage()
26 matches
Mail list logo
