Quantcast

DWR EXCEPTION Handling

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

DWR EXCEPTION Handling

David K-3
It's now no setter fur exception handling.

we must do DWREngine._exceptionHandler = fctErrorDWRHandler;
is that normal  ?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DWR EXCEPTION Handling

JoeWalker

On 11/17/06, David K <[hidden email]> wrote:
It's now no setter fur exception handling.

we must do DWREngine._exceptionHandler = fctErrorDWRHandler;
is that normal  ?

No. All dwr.engine._* members are private. Their use may well break in the future.
You set an exception handler like this:

Remote.method(params, {
  callback:...,
  exceptionHandler:...
});

Exception handlers are specific to calls, just as try/catch is specific to where a call is made. If an exception happens without an exceptionHandler, then an error is raised.

Joe.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DWR EXCEPTION Handling

David K-3
yes but i want that all exception will handler by my default function and not the DWR default exeption function

2006/11/17, Joe Walker <[hidden email]>:

On 11/17/06, David K <[hidden email]> wrote:
It's now no setter fur exception handling.

we must do DWREngine._exceptionHandler = fctErrorDWRHandler;
is that normal  ?

No. All dwr.engine._* members are private. Their use may well break in the future.
You set an exception handler like this:

Remote.method(params, {
  callback:...,
  exceptionHandler:...
});

Exception handlers are specific to calls, just as try/catch is specific to where a call is made. If an exception happens without an exceptionHandler, then an error is raised.

Joe.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DWR EXCEPTION Handling

David K-3
you can not make that so as dwr.engine.setExceptionHandler(handler) ??

2006/11/17, David K <[hidden email]>:
yes but i want that all exception will handler by my default function and not the DWR default exeption function

2006/11/17, Joe Walker <[hidden email]>:

On 11/17/06, David K <[hidden email]> wrote:
It's now no setter fur exception handling.

we must do DWREngine._exceptionHandler = fctErrorDWRHandler;
is that normal  ?

No. All dwr.engine._* members are private. Their use may well break in the future.
You set an exception handler like this:

Remote.method(params, {
  callback:...,
  exceptionHandler:...
});

Exception handlers are specific to calls, just as try/catch is specific to where a call is made. If an exception happens without an exceptionHandler, then an error is raised.

Joe.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DWR EXCEPTION Handling

JoeWalker


On 11/17/06, David K <[hidden email]> wrote:
you can not make that so as dwr.engine.setExceptionHandler(handler) ??

Why? you can use the error handler if you really need to do that.

Joe.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DWR EXCEPTION Handling

David K-3
no, i have developp a very big application for my entreprise with your DWR project. When i want to generate an error, i generate a rollbackexception if i am in a transaction or a simply exception ( throw new exception("message") ) .

With old DWR version, this generate a DWR ERROR and i get the error with my javascript function (this for all error).

With new DWR version this not work with errorhandler, this work with exceptionhandler, errorHandler does not take the hand, and i want not change every AJAX function of my application.

Please create a setters for default exceptionHandler so as errorHandler. Please that's come from my heart ;-)

2006/11/17, Joe Walker <[hidden email]>:


On 11/17/06, David K <[hidden email]> wrote:
you can not make that so as dwr.engine.setExceptionHandler(handler) ??

Why? you can use the error handler if you really need to do that.

Joe.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DWR EXCEPTION Handling

JoeWalker

Maybe I'm not saying this clearly enough.

With DWR 2, when an exception is raised, AND there is no exceptionHandler, the errorHandler gets called in it's place. Just like before.

There may be a bug in the handling of errors, it's something that I'm creating tests for at the moment, but there is no plan to create a global exception handler because I don't see the need for one.

Joe.

On 11/17/06, David K <[hidden email]> wrote:
no, i have developp a very big application for my entreprise with your DWR project. When i want to generate an error, i generate a rollbackexception if i am in a transaction or a simply exception ( throw new exception("message") ) .

With old DWR version, this generate a DWR ERROR and i get the error with my javascript function (this for all error).

With new DWR version this not work with errorhandler, this work with exceptionhandler, errorHandler does not take the hand, and i want not change every AJAX function of my application.

Please create a setters for default exceptionHandler so as errorHandler. Please that's come from my heart ;-)

2006/11/17, Joe Walker <[hidden email]>:


On 11/17/06, David K <[hidden email]> wrote:
you can not make that so as dwr.engine.setExceptionHandler(handler) ??

Why? you can use the error handler if you really need to do that.

Joe.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DWR EXCEPTION Handling

Andreas Schmidt-4
In reply to this post by JoeWalker
the current _exceptionHandler doesn't call the errorHandler, but the
defaultErrorHandler. so it's of no use to set an errorHandler if you
need a "global" exceptionHandler.

but i don't like the idea to add another global setXXXHandler to the
dwr-interface.

from my point of view, exceptions of remote calls need a call-specific
exception handler. if you miss to define one, you can't do specific
exceptionHandling, so it's of limited use to differ between errors and
exceptions anylonger.

so instead of having to add another global handler to dwr, i would
suggest to implement dwr.engine._exceptionHandler kind of like this:

dwr.engine._exceptionHandler = function(message,ex){
        if( dwr.engine._errorHandler ) {
                dwr.engine._errorHandler( {
                        name:"dwr.engine.unhandledException",
                        message:"unhandled exception: "+ex.name,
                        ex:ex
                });
        }
}

regards,
        andi



Joe Walker schrieb:

>
>
> On 11/17/06, *David K* <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     you can not make that so as dwr.engine.setExceptionHandler(handler) ??
>
>
> Why? you can use the error handler if you really need to do that.
>
> Joe.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DWR EXCEPTION Handling

JoeWalker

My current change, which I made before I saw your suggestion is a tweak to remoteHandleException() to check for errorHandlers properly rather than running to the default.

Just checking into CVS for comment.

Joe.


On 11/17/06, Andreas Schmidt <[hidden email]> wrote:
the current _exceptionHandler doesn't call the errorHandler, but the
defaultErrorHandler. so it's of no use to set an errorHandler if you
need a "global" exceptionHandler.

but i don't like the idea to add another global setXXXHandler to the
dwr-interface.

from my point of view, exceptions of remote calls need a call-specific
exception handler. if you miss to define one, you can't do specific
exceptionHandling, so it's of limited use to differ between errors and
exceptions anylonger.

so instead of having to add another global handler to dwr, i would
suggest to implement dwr.engine._exceptionHandler kind of like this:

dwr.engine._exceptionHandler = function(message,ex){
        if( dwr.engine._errorHandler ) {
                dwr.engine._errorHandler( {
                        name:"dwr.engine.unhandledException",
                        message:"unhandled exception: "+ex.name,
                        ex:ex
                });
        }
}

regards,
        andi



Joe Walker schrieb:

>
>
> On 11/17/06, *David K* <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     you can not make that so as dwr.engine.setExceptionHandler(handler) ??
>
>
> Why? you can use the error handler if you really need to do that.
>
> Joe.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DWR EXCEPTION Handling

gvenkat
In reply to this post by JoeWalker
Is this new in DWR2.X ?  
Remote.method(params, { callback:...,  exceptionHandler:... });
In dwr1.1 I see this signature for calling..
Remote.method(callbackMethod, params... )

Thanks
Venkat
JoeWalker wrote
On 11/17/06, David K <boblepepeur@gmail.com> wrote:
>
> It's now no setter fur exception handling.
>
> we must do DWREngine._exceptionHandler = fctErrorDWRHandler;
> is that normal  ?
>

No. All dwr.engine._* members are private. Their use may well break in the
future.
You set an exception handler like this:

Remote.method(params, {
  callback:...,
  exceptionHandler:...
});

Exception handlers are specific to calls, just as try/catch is specific to
where a call is made. If an exception happens without an exceptionHandler,
then an error is raised.

Joe.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DWR EXCEPTION Handling

Andreas Schmidt-4
In reply to this post by JoeWalker
somehow i liked the idea to wrap an unhandled call-exception in a
dwr.engine-error before calling an errorHandler. but that's not important.

and it's good that you now check for a batch-errorhandler as well.

but: the batch-errorhandler is per default set to the global
errorhandler. so the condition typeof batch.errorhandler == function is
always true unless the user overwrites dwr.engine._errorhandler or
batch.errorhandler with null or some (invalid?) non-function value. is
this allowed to suppress errorhandling instead of setting a
NOP-errorhandler? if so, i think we shouldn't call the global
errorhandler as last resort, because we ignore the user's wish to
suppress errorhandling on a batch. (btw: you use the same logic in
handleError and handleWarning)

regards,
        andi

Joe Walker schrieb:

>
> My current change, which I made before I saw your suggestion is a tweak
> to remoteHandleException() to check for errorHandlers properly rather
> than running to the default.
>
> Just checking into CVS for comment.
>
> Joe.
>
>
> On 11/17/06, *Andreas Schmidt* <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     the current _exceptionHandler doesn't call the errorHandler, but the
>     defaultErrorHandler. so it's of no use to set an errorHandler if you
>     need a "global" exceptionHandler.
>
>     but i don't like the idea to add another global setXXXHandler to the
>     dwr-interface.
>
>     from my point of view, exceptions of remote calls need a call-specific
>     exception handler. if you miss to define one, you can't do specific
>     exceptionHandling, so it's of limited use to differ between errors and
>     exceptions anylonger.
>
>     so instead of having to add another global handler to dwr, i would
>     suggest to implement dwr.engine._exceptionHandler kind of like this:
>
>     dwr.engine._exceptionHandler = function(message,ex){
>             if( dwr.engine._errorHandler ) {
>                     dwr.engine._errorHandler( {
>                             name:"dwr.engine.unhandledException",
>                             message:"unhandled exception: "+ex.name,
>                             ex:ex
>                     });
>             }
>     }
>
>     regards,
>             andi
>
>
>
>     Joe Walker schrieb:
>      >
>      >
>      > On 11/17/06, *David K* < [hidden email]
>     <mailto:[hidden email]>
>      > <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>      >
>      >     you can not make that so as
>     dwr.engine.setExceptionHandler(handler) ??
>      >
>      >
>      > Why? you can use the error handler if you really need to do that.
>      >
>      > Joe.
>      >
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DWR EXCEPTION Handling

JoeWalker
In reply to this post by gvenkat


On 11/17/06, gvenkat <[hidden email]> wrote:

Is this new in DWR2.X ?

Remote.method(params, { callback:...,  exceptionHandler:... });
In dwr1.1 I see this signature for calling..
Remote.method(callbackMethod, params... )


Joe.
 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DWR EXCEPTION Handling

JoeWalker
In reply to this post by Andreas Schmidt-4

Wow! I'm not sure you understand engine.js better than I do.
Thanks. I've taken out the global check.

Joe.

On 11/17/06, Andreas Schmidt < [hidden email]> wrote:
somehow i liked the idea to wrap an unhandled call-exception in a
dwr.engine-error before calling an errorHandler. but that's not important.

and it's good that you now check for a batch-errorhandler as well.

but: the batch-errorhandler is per default set to the global
errorhandler. so the condition typeof batch.errorhandler == function is
always true unless the user overwrites dwr.engine._errorhandler or
batch.errorhandler with null or some (invalid?) non-function value. is
this allowed to suppress errorhandling instead of setting a
NOP-errorhandler? if so, i think we shouldn't call the global
errorhandler as last resort, because we ignore the user's wish to
suppress errorhandling on a batch. (btw: you use the same logic in
handleError and handleWarning)

regards,
        andi

Joe Walker schrieb:

>
> My current change, which I made before I saw your suggestion is a tweak
> to remoteHandleException() to check for errorHandlers properly rather
> than running to the default.
>
> Just checking into CVS for comment.
>
> Joe.
>
>
> On 11/17/06, *Andreas Schmidt* < [hidden email]
> <mailto:[hidden email]>> wrote:
>
>     the current _exceptionHandler doesn't call the errorHandler, but the
>     defaultErrorHandler. so it's of no use to set an errorHandler if you
>     need a "global" exceptionHandler.
>
>     but i don't like the idea to add another global setXXXHandler to the
>     dwr-interface.
>
>     from my point of view, exceptions of remote calls need a call-specific
>     exception handler. if you miss to define one, you can't do specific
>     exceptionHandling, so it's of limited use to differ between errors and
>     exceptions anylonger.
>
>     so instead of having to add another global handler to dwr, i would
>     suggest to implement dwr.engine._exceptionHandler kind of like this:
>
>     dwr.engine._exceptionHandler = function(message,ex){
>             if( dwr.engine._errorHandler ) {
>                     dwr.engine._errorHandler( {
>                             name:"dwr.engine.unhandledException ",
>                             message:"unhandled exception: "+ex.name,
>                             ex:ex
>                     });
>             }
>     }
>
>     regards,
>             andi
>
>
>
>     Joe Walker schrieb:
>      >
>      >
>      > On 11/17/06, *David K* < [hidden email]
>     <mailto:[hidden email]>
>      > <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>      >
>      >     you can not make that so as
>     dwr.engine.setExceptionHandler(handler) ??
>      >
>      >
>      > Why? you can use the error handler if you really need to do that.
>      >
>      > Joe.
>      >
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DWR EXCEPTION Handling

Andreas Schmidt-4
does that mean, that it is legal (and should work) to do something like

dwr.engine.endBatch({
        errorHandler:null
})

to suppress errorHandling for a batch?

i'm no expert with null/undefined values in the various
javascript-implementatations. but i think the current
dwr.engine._mergeBatch-implementation would ignore the null-value and
not overwrite the default errorHandler unless you change

if (overrides[propname] != null) batch[propname] = overrides[propname];

to

if ( typeof overrides[propname] != "undefined") batch[propname] =
overrides[propname];

regards,
        andi

Joe Walker schrieb:

>
> Wow! I'm not sure you understand engine.js better than I do.
> Thanks. I've taken out the global check.
>
> Joe.
>
> On 11/17/06, *Andreas Schmidt* < [hidden email]
> <mailto:[hidden email]>> wrote:
>
>     somehow i liked the idea to wrap an unhandled call-exception in a
>     dwr.engine-error before calling an errorHandler. but that's not
>     important.
>
>     and it's good that you now check for a batch-errorhandler as well.
>
>     but: the batch-errorhandler is per default set to the global
>     errorhandler. so the condition typeof batch.errorhandler == function is
>     always true unless the user overwrites dwr.engine._errorhandler or
>     batch.errorhandler with null or some (invalid?) non-function value. is
>     this allowed to suppress errorhandling instead of setting a
>     NOP-errorhandler? if so, i think we shouldn't call the global
>     errorhandler as last resort, because we ignore the user's wish to
>     suppress errorhandling on a batch. (btw: you use the same logic in
>     handleError and handleWarning)
>
>     regards,
>             andi
>
>     Joe Walker schrieb:
>
>      >
>      > My current change, which I made before I saw your suggestion is a
>     tweak
>      > to remoteHandleException() to check for errorHandlers properly rather
>      > than running to the default.
>      >
>      > Just checking into CVS for comment.
>      >
>      > Joe.
>      >
>      >
>      > On 11/17/06, *Andreas Schmidt* < [hidden email]
>     <mailto:[hidden email]>
>      > <mailto:[hidden email]
>     <mailto:[hidden email]>>> wrote:
>      >
>      >     the current _exceptionHandler doesn't call the errorHandler,
>     but the
>      >     defaultErrorHandler. so it's of no use to set an errorHandler
>     if you
>      >     need a "global" exceptionHandler.
>      >
>      >     but i don't like the idea to add another global setXXXHandler
>     to the
>      >     dwr-interface.
>      >
>      >     from my point of view, exceptions of remote calls need a
>     call-specific
>      >     exception handler. if you miss to define one, you can't do
>     specific
>      >     exceptionHandling, so it's of limited use to differ between
>     errors and
>      >     exceptions anylonger.
>      >
>      >     so instead of having to add another global handler to dwr, i
>     would
>      >     suggest to implement dwr.engine._exceptionHandler kind of
>     like this:
>      >
>      >     dwr.engine._exceptionHandler = function(message,ex){
>      >             if( dwr.engine._errorHandler ) {
>      >                     dwr.engine._errorHandler( {
>      >                             name:"dwr.engine.unhandledException ",
>      >                             message:"unhandled exception: "+ex.name,
>      >                             ex:ex
>      >                     });
>      >             }
>      >     }
>      >
>      >     regards,
>      >             andi
>      >
>      >
>      >
>      >     Joe Walker schrieb:
>      >      >
>      >      >
>      >      > On 11/17/06, *David K* < [hidden email]
>     <mailto:[hidden email]>
>      >     <mailto:[hidden email] <mailto:[hidden email]>>
>      >      > <mailto:[hidden email]
>     <mailto:[hidden email]> <mailto: [hidden email]
>     <mailto:[hidden email]>>>> wrote:
>      >      >
>      >      >     you can not make that so as
>      >     dwr.engine.setExceptionHandler(handler) ??
>      >      >
>      >      >
>      >      > Why? you can use the error handler if you really need to
>     do that.
>      >      >
>      >      > Joe.
>      >      >
>      >
>      >    
>     ---------------------------------------------------------------------
>      >     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>      >     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>      >     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>      >     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>      >
>      >
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DWR EXCEPTION Handling

gvenkat
In reply to this post by JoeWalker
Focus of error handler is given to client code (javascript). Agreed the end error need to reflect at client & handled/shown to client.    
But  giving once last change to sever code (java code) before throwing Exception to client can be considered.  .  
This is what I mean:     DWRServlet is executing each java method, in some cases it gets Exceptions (even runtime), this can be passed to java server code, which can handle this kind of error situation better then client.   An global error handler can be registered to  DWR using dwr.xml we have etc.  In absence of this & if that java error handler throws an error, we can give control to javascript (client).
I some how feel,  this is a cleaner way( and easier for DWR & dwr users :-) , please educate me if I am missing any..


Thanks
Venkat

JoeWalker wrote
On 11/17/06, David K <boblepepeur@gmail.com> wrote:
>
> you can not make that so as dwr.engine.setExceptionHandler(handler) ??


Why? you can use the error handler if you really need to do that.

Joe.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DWR EXCEPTION Handling

Andreas Schmidt-4
i don't agree with you. what we were talking about are exeptions thrown
by your remote objects. if you want to handle these exceptions on the
server side, why don't you do write exception handlers in your remote
objects? from my point of view dwr isn't responsibe for server side
error handling. dwr should only provide a way to forward exceptions to
the client side, if you can't handle them in your remote objects.

regards,
        andi

btw: if you can write a universal errorhandler that can handle all your
possible exceptions for all your remote objects on the server side,
maybe it's possible to use the ajaxFilter-feature to implement such an
errorhandler? could be worth a closer look.

gvenkat schrieb:

> Focus of error handler is given to client code (javascript). Agreed the end
> error need to reflect at client & handled/shown to client.    
> But  giving once last change to sever code (java code) before throwing
> Exception to client can be considered.  .  
> This is what I mean:     DWRServlet is executing each java method, in some
> cases it gets Exceptions (even runtime), this can be passed to java server
> code, which can handle this kind of error situation better then client.   An
> global error handler can be registered to  DWR using dwr.xml we have etc.
> In absence of this & if that java error handler throws an error, we can give
> control to javascript (client).
> I some how feel,  this is a cleaner way( and easier for DWR & dwr users :-)
> , please educate me if I am missing any..
>
>
> Thanks
> Venkat
>
>
> JoeWalker wrote:
>
>>On 11/17/06, David K <[hidden email]> wrote:
>>
>>>you can not make that so as dwr.engine.setExceptionHandler(handler) ??
>>
>>
>>Why? you can use the error handler if you really need to do that.
>>
>>Joe.
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DWR EXCEPTION Handling

gvenkat
In my application we have about 200+ remote methods that we expose to DWR for getting called from client.  To handle exceptions throwned by thouse methods I need to put try/catch methods & make sure those methods does not throw any exceptions.  It is not correct to put so many catch blocks in system.
In my view, DWR has a easy way to fix this issue and it is one other way for programmer to fix his exception, or do any thing in that time.  All it has to do is call one other method before throwing excretion to client code.

Andi, thanks for your suggestion 'ajax-filters'  I will look at it.  

BTW:   I put one other post  " DWR - Exception handling by gvenkat  "     where I given how I am working around with common server side error handler.  For some reason I do not see any response to that post.  Is any thing wrong with that post?. I am new to this Forums.

Thanks
Venkat

Andreas Schmidt-4 wrote
i don't agree with you. what we were talking about are exeptions thrown
by your remote objects. if you want to handle these exceptions on the
server side, why don't you do write exception handlers in your remote
objects?

from my point of view dwr isn't responsibe for server side
error handling. dwr should only provide a way to forward exceptions to
the client side, if you can't handle them in your remote objects.

regards,
        andi

btw: if you can write a universal errorhandler that can handle all your
possible exceptions for all your remote objects on the server side,
maybe it's possible to use the ajaxFilter-feature to implement such an
errorhandler? could be worth a closer look.

gvenkat schrieb:
> Focus of error handler is given to client code (javascript). Agreed the end
> error need to reflect at client & handled/shown to client.    
> But  giving once last change to sever code (java code) before throwing
> Exception to client can be considered.  .  
> This is what I mean:     DWRServlet is executing each java method, in some
> cases it gets Exceptions (even runtime), this can be passed to java server
> code, which can handle this kind of error situation better then client.   An
> global error handler can be registered to  DWR using dwr.xml we have etc.
> In absence of this & if that java error handler throws an error, we can give
> control to javascript (client).
> I some how feel,  this is a cleaner way( and easier for DWR & dwr users :-)
> , please educate me if I am missing any..
>
>
> Thanks
> Venkat
>
>
> JoeWalker wrote:
>
>>On 11/17/06, David K <boblepepeur@gmail.com> wrote:
>>
>>>you can not make that so as dwr.engine.setExceptionHandler(handler) ??
>>
>>
>>Why? you can use the error handler if you really need to do that.
>>
>>Joe.
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@dwr.dev.java.net
For additional commands, e-mail: users-help@dwr.dev.java.net
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DWR EXCEPTION Handling

gvenkat
In reply to this post by JoeWalker
Thanks for your response .
BTW:  I did not get any responce to my post  "DWR - Exception handling by gvenkat ".   Can every one see that post?  is there any issue with that post? I am new to this forums..  
(Not that one should get a response to all posts ;)  but I see responses to all posts expect that !! ;-)

Thanks
Venkat  

JoeWalker wrote
On 11/17/06, gvenkat <gvchalapathy@yahoo.com> wrote:
>
>
> Is this new in DWR2.X ?


Yes.
http://getahead.ltd.uk/dwr/browser/engine

Remote.method(params, { callback:...,  exceptionHandler:... });
> In dwr1.1 I see this signature for calling..
> Remote.method(callbackMethod, params... )



Joe.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DWR EXCEPTION Handling

David K-3
i manage all my error or exception by the same code, i manage loading message and modal div. i think that every one can do what here want to do and i  want not write all my function with execptionhandler : function because for all my ajax function i use the same code to for example hide my loading message ;-) my english is bad sorry i m french ;-)



2006/11/18, gvenkat <[hidden email]>:

Thanks for your response .
BTW:  I did not get any responce to my post  "DWR - Exception handling by
gvenkat ".   Can every one see that post?  is there any issue with that
post? I am new to this forums..
(Not that one should get a response to all posts ;)  but I see responses to
all posts expect that !! ;-)

Thanks
Venkat


JoeWalker wrote:

>
> On 11/17/06, gvenkat <[hidden email]> wrote:
>>
>>
>> Is this new in DWR2.X ?
>
>
> Yes.
> http://getahead.ltd.uk/dwr/browser/engine
>
> Remote.method(params, { callback:...,  exceptionHandler:... });
>> In dwr1.1 I see this signature for calling..
>> Remote.method(callbackMethod, params... )
>
>
>
> Joe.
>
>

--
View this message in context: http://www.nabble.com/DWR-EXCEPTION-Handling-tf2650043.html#a7413917
Sent from the DWR - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DWR EXCEPTION Handling

Andreas Schmidt-4
In reply to this post by gvenkat


gvenkat schrieb:
> In my application we have about 200+ remote methods that we expose to DWR for
> getting called from client.  To handle exceptions throwned by thouse methods
> I need to put try/catch methods & make sure those methods does not throw any
> exceptions.  It is not correct to put so many catch blocks in system.
> In my view, DWR has a easy way to fix this issue and it is one other way for
> programmer to fix his exception, or do any thing in that time.  All it has
> to do is call one other method before throwing excretion to client code.

i understand why you like to have a central error handling, but it still
disagree that dwr should provide something for that. from my point of
view, remote objects should only pass those exceptions to dwr that shall
find their way to the client (dwr is the infrastructure for connecting
clients with java-objects). if you need central errorhandling for your
java-classes on the server side, you sould be able to find a solution
for this before you pass the exception to dwr.

if ajax-filters allow you to build this, that's fine. (i had a quick
look into DefaultRemoter.java and ExecuteAjaxFilter.java and it looks as
if it should be possible and quite easy). if not, maybe you can use some
kind of dynamic proxy implementation that does this for all your remote
objects. (if you use the springframework on the server side, this should
be quite easy to implement)

> Andi, thanks for your suggestion 'ajax-filters'  I will look at it.  
>
> BTW:   I put one other post  " DWR - Exception handling by gvenkat  "    
> where I given how I am working around with common server side error handler.
> For some reason I do not see any response to that post.  Is any thing wrong
> with that post?. I am new to this Forums.

i've seen your post, and from my point of view there's nothing wrong
with it. except that i don't have a clue, what goes wrong there. and
since your approach to send back exceptions to the server seems kind of
exotic, i doubt others have tried this before and can help you with that.

so if you want to keep on going in that direction, i fear you have to
dig into the sourcecode yourself.

but i think, it's more reasonable to look for a solution to catch your
exceptions on the server side instead of sending them back.

just my two cents,
        andi

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12
Loading...