I was compelled to do so because Java told me I had to. This was,
however, due to my own stupid mistake. I made a copy of my interface
to create the Async version. But I forgot to remove the throws clause
from the Async interface. This caused Java to require a try catch
block around my actual call.
Luckely it was all my bad and the world is safe once again. :)
I hope nobody else falls for this one, it cost me a lot of time
figuring out what went wrong.
With regards, Patrick
PS: Thank you for your help Isaac!
On Nov 19, 6:48 pm, "Isaac Truett" <[EMAIL PROTECTED]> wrote:
> Exceptions thrown by the server end up in the onFailure method, as
> you've already seen. There's nothing evil, dirty, or morally wrong
> with the server throwing those exceptions. My question was, why do you
> feel compelled to put your RPC call site in a try/catch block? That
> method, as you know, cannot throw an exception. Are you declaring your
> *Async interface methods with thrown exceptions?
>
> On Wed, Nov 19, 2008 at 12:37 PM, Patrick Ratelband <[EMAIL PROTECTED]> wrote:
>
> > Since the method I use on the server side can throw an exception, java
> > (or Eclipse at least, perhaps that is at fault, I have not checked
> > that) can throw an exception. Is the correct wat to handle this then
> > to never throw exceptions from the server to the client, but to start
> > working with null values and -1 values to show an error in the method?
> > This feel really wrong to me to do t.b.h..
>
> > Patrick
>
> > On Nov 19, 3:10 pm, "Isaac Truett" <[EMAIL PROTECTED]> wrote:
> >> > Am I making a fundamental flaw in my logic[?]
>
> >> Yes.
>
> >> You already seem to know the why of it: it's an asynchronous call and
> >> the try/catch has already executed before the response is received.
> >> You can't hang around in the try/catch waiting for a response because
> >> that isn't asynchronous.
>
> >> If you search for "beer" in the forum history, you'll find an amusing
> >> and much longer explanation of why asynchronous is good and the
> >> alternative is bad, by Jason Essington.
>
> >> >but the actual call still needs to have a try-catch-block
>
> >> Why is that?
>
> >> On Wed, Nov 19, 2008 at 7:23 AM, Patrick Ratelband <[EMAIL PROTECTED]>
> >> wrote:
>
> >> > Hey everyone,
>
> >> > I am trying to determine the location where an exception is caught in
> >> > the client side of a bit of code.
>
> >> > With a little testing I have found that throwing an exception in a RPC
> >> > call will be caught by the onFailure clause of that specific call,
> >> > however, since I would like to use the exceptions higher up, it feels
> >> > like they should be caught by the try-catch-block around the actual
> >> > invocation.
>
> >> > The example code below should clarify what I mean. The remote method
> >> > test will simply throw an Exception when called.
>
> >> > ...
>
> >> > // Setup
> >> > ExTestServiceAsync serviceProxy = (ExTestServiceAsync) GWT.create
> >> > (ExTestService.class);
> >> > ((ServiceDefTarget)serviceProxy).setServiceEntryPoint
> >> > (GWT.getModuleBaseURL() + "ExTestService");
> >> > AsyncCallback<String> callback = new AsyncCallback<String>() {
> >> > public void onFailure (Throwable caught) {
>
> >> > GWT.log("RPC error", caught); // <-- This is what is
> >> > triggered and
> >> > what shows in the GWT log window.
>
> >> > }
> >> > public void onSuccess (String result) {
> >> > GWT.log("RPC Succes: ", null);
> >> > }
> >> > };
>
> >> > ...
>
> >> > // Make the call
> >> > try {
> >> > serviceProxy.test(true, callback);
> >> > } catch (Exception e) {
>
> >> > GWT.log("Exception while attempting RPC.", null); <-- This is
> >> > where I
> >> > would like the exception to be caught.
>
> >> > }
>
> >> > ...
>
> >> > As you can see, the exception that is thrown is caught in the wrong
> >> > place IMHO. It feels like the onFailure should only fire when the RPC
> >> > mechanism has a problem (something that GWT should generate) and an
> >> > exception that is thrown by programmer code should be handled in the
> >> > catch block of the actual call.
>
> >> > I understand that this will most likely yield tons of problems with
> >> > the whole asynchronous thing (in fact I am sure one excludes the
> >> > other), but the actual call still needs to have a try-catch-block
> >> > which seems never to be called.
>
> >> > Am I making a fundamental flaw in my logic or is this an unresolved
> >> > issue?
>
> >> > Patrick
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
