debugging async request handlers ...

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

debugging async request handlers ...

oetiker
Gurus,

I am writing an application that runs quite a substantial bit of
code in response to data coming in from the client side ... as with
all code there are bugs in the request handler ...

unfortunately these bugs get caught by the RequestQueue.js which then
prints the following line on the console.

 408366 qx.io.remote.RequestQueue[28]: Request qx.io.remote.Request[o8] handler _oncompleted threw an error.

not exactly helpful ... if there was no try/catch block when
runnning the request handler I would get instant feedback on the
problem in my code ...

idealy there would not be any trying and
catching going on while the code was runnning in debug mode.
only the production version should do the catching ...

since it is not clear to me how this would be implemented properly in the
qx context, I am consoling myself with the following patch,
so that I at least get the original error message (no line number
and such luxury, but at least the error text ... )

Index: /usr/pack/qooxdoo-0.8svn-to/frontend/framework/source/class/qx/io/remote/RequestQueue.js
===================================================================
--- /usr/pack/qooxdoo-0.8svn-to/frontend/framework/source/class/qx/io/remote/RequestQueue.js    (revision 20668)
+++ /usr/pack/qooxdoo-0.8svn-to/frontend/framework/source/class/qx/io/remote/RequestQueue.js    (working copy)
@@ -345,7 +345,7 @@
       catch(e)
       {
         this.error("Request " + request + " handler " + requestHandler +
-                   " threw an error.");
+                   " threw an error: " + e);

         // Issue an "aborted" event so the application gets notified.
         // If that too fails, or if there's no "aborted" handler, ignore it.

cheers
tobi


--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch [hidden email] ++41 62 775 9902 / sb: -9900

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: debugging async request handlers ...

Fabian Jakobs
Administrator
Hi Tobias,

you are right, these try/catch blocks can make it really hard to debug
exceptions. I've extended you change a little bit. In browser, which
support it, it will now print the stack trace of the exception as well.

        this.error(
          "Request " + request + " handler " + requestHandler + " threw
an error: " + ex +
          "\nStack Trace:\n" +
          qx.dev.StackTrace.getStackTraceFromError(ex)
        );


Best Fabian

This should print the stacktrace

> Gurus,
>
> I am writing an application that runs quite a substantial bit of
> code in response to data coming in from the client side ... as with
> all code there are bugs in the request handler ...
>
> unfortunately these bugs get caught by the RequestQueue.js which then
> prints the following line on the console.
>
>  408366 qx.io.remote.RequestQueue[28]: Request qx.io.remote.Request[o8] handler _oncompleted threw an error.
>
> not exactly helpful ... if there was no try/catch block when
> runnning the request handler I would get instant feedback on the
> problem in my code ...
>
> idealy there would not be any trying and
> catching going on while the code was runnning in debug mode.
> only the production version should do the catching ...
>
> since it is not clear to me how this would be implemented properly in the
> qx context, I am consoling myself with the following patch,
> so that I at least get the original error message (no line number
> and such luxury, but at least the error text ... )
>
> Index: /usr/pack/qooxdoo-0.8svn-to/frontend/framework/source/class/qx/io/remote/RequestQueue.js
> ===================================================================
> --- /usr/pack/qooxdoo-0.8svn-to/frontend/framework/source/class/qx/io/remote/RequestQueue.js    (revision 20668)
> +++ /usr/pack/qooxdoo-0.8svn-to/frontend/framework/source/class/qx/io/remote/RequestQueue.js    (working copy)
> @@ -345,7 +345,7 @@
>        catch(e)
>        {
>          this.error("Request " + request + " handler " + requestHandler +
> -                   " threw an error.");
> +                   " threw an error: " + e);
>
>          // Issue an "aborted" event so the application gets notified.
>          // If that too fails, or if there's no "aborted" handler, ignore it.
>
> cheers
> tobi
>
>
>  


--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG - Web Technologies
Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
Telefon: +49 721 91374-6784
[hidden email]

Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel