Re: getting exceptions from the server to client in ROP

From: Marek Wawrzyczny (marek_wawrzyczn..nternode.on.net)
Date: Mon Jul 16 2007 - 01:16:18 EDT

  • Next message: Andrus Adamchik: "Re: How to use left outer join / left join in cayenne?"

    On Sun, 15 Jul 2007 06:43:53 Andrus Adamchik wrote:
    > On Jul 13, 2007, at 4:56 AM, Aristedes Maniatis wrote:
    > > 1. It isn't our problem. The bug in Derby is going away and Hessian
    > > is working around it too. Leave it as it is and put some notes in
    > > the docs for people 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, more
    > important reason why it won't work - client may not (and should not)
    > have all server classes in its CLASSPATH and therefore will not be
    > able to de-serialize many of the exception classes.
    >
    > Theoretically any server component can throw a runtime exception.
    > JDBC driver and server-side callback methods are the two most likely
    > cases. You probably don't want to keep all server jar baggage on the
    > client - that kind of kills all the ROP appeal.
    >
    > > 2. Add the original exception's stack trace to the CRE message.
    > > Simple to do, but slightly ugly in that it fills up the previously
    > > concise message with stack trace. Some users may expect their
    > > message to be short and sweet.
    > >
    > > 3. Add new fields to CRE which are guaranteed to serialise (such as
    > > String causedByStackTrace and causedByClassName) which can contain
    > > this information. But then it is a bit more effort to get them out
    > > on the client (say within log4j).
    >
    > Maybe we can build upon #3:
    >
    > 4. Subclass a CRE, creating a special exception thrown by the
    > service, that has an extra field storing a String representation of
    > the cause stack trace.
    >
    > Andrus

    Hi,

    Long time lurker seldom poster :)

    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 sent now,
    however the true stack trace could be saved to a log file or emailed (for
    example) by custom server-side code.

    Marek

    This archive was generated by hypermail 2.0.0 : Mon Jul 16 2007 - 01:16:10 EDT