Exceptions Handling

[dimakura]

There are some problems with accurate error handling.

When my service generates SQLException, for example, then i only get
"InvocationException" which doesnot contains causes (simply "See
server log"). This is a problem in many situations.

When i try to define exceptions exactly in the "throw" declaration of
the service method, then compiler not compiles this code (no matter
whether i define the same declarations in asynchronous interface).

Of cause, i can return exception object and get it in "onSuccess", but
it not seems to be a good idea.

May be someone tells me how to manage this situation in most
consistent way.

regards, dimitri

[Reinier Zwitserloot]

How can you possibly throw or handle SQLException in GWT?

SQL is databases.

GWT runs on the client. Which doesn't have one.

I think your troubles are caused by not realizing that GWT is simply a
way to write client-side code. Meaning, there is no java.io, and there
is no java.sql or JDBC.

Maybe it sorta works in hosting mode, but once you take it to a real
browser it definitely won't.

[mithrandir]

define an own exception class MyEx which extends exception has an
attribute message, an empty constructor and a Construct MyEx(String
message), a method getMessage(). Then catch the sql exception "sqlex"
or whatever on server side and instantiate My ex with new
MyEx(sqlex.getMessage + sql.getStackTrace()) and throw it. On client
side you can now display the information by using caught.getMessage().

[dimakura]

I understand that client side does not recognize SQLException: it is
unsupported API.

I say about my custom exception class which holds details about server-
side problem: some textual or even pure "exception code" information.
Any problem on server side is returned as "InvocationException". How
to recognize the underling problem?

[Reinier Zwitserloot]

e.getCause();

[Jason Essington]

Basically, exceptions thrown from your RPC service implementations
need to follow the same rules as custom objects used with RPC. They
need to be serializeable, you'll have to override the setMessage()
method and store your message in a field in your custom exception.

so, you would have to define something like DatabaseException
then in your service implementation, catch the SQLException, and
rethrow the exception as a DatabaseException.

Also, your service interface will need to have throws declarations on
the methods that are expected to throw the custom exception.

-jason

[dimakura]

Unfortunatly

/////
e.getCause() == null (!!!)
at least when
e instanceof InvocationException
////

[dimakura]

I think this is a good advice. I'll try.
Thanks.

On Feb 10, 3:58 pm, "Jason Essington" <jason.essing...@gmail.com>
wrote:

> Basically, exceptions thrown from your RPC service implementations
> need to follow the same rules as custom objects used with RPC. They
> need to be serializeable, you'll have to override the setMessage()
> method and store your message in a field in your custom exception.
>
> so, you would have to define something like DatabaseException
> then in your service implementation, catch the SQLException, and
> rethrow the exception as a DatabaseException.
>
> Also, your service interface will need to have throws declarations on
> the methods that are expected to throw the custom exception.
>
> -jason
>