You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Thorsten Schöning <ts...@am-soft.de> on 2016/05/03 14:22:01 UTC
Provide error message for Ajax requests in DefaultExceptionMapper?
Hi all,
> private IRequestHandler internalMap(Exception e)
[...]
> switch (application.getExceptionSettings().getAjaxErrorHandlingStrategy())
> {
> case INVOKE_FAILURE_HANDLER :
> return new ErrorCodeRequestHandler(500);
> }
Is there any reason why the request handler doesn't get any message
retrieved from the available exception? The exception message may span
multiple lines and such of course, but such things could be filtered.
Currently only getting 500 without any hint to what's actually wrong
looks a bit wasteful.
Especially if I see lines like the following in ServletWebRequest:
> throw new AbortWithHttpErrorCodeException(HttpServletResponse.SC_BAD_REQUEST,
> "Current ajax request is missing the base url header or parameter");
So you already have places where you end with custom messages.
Is this something worth filing as an enhancement in JIRA?
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Provide error message for Ajax requests in DefaultExceptionMapper?
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Martin Grigorov,
am Dienstag, 3. Mai 2016 um 15:35 schrieben Sie:
> Configuring your own IExceptionMapper[...]
I already use a custom exception mapper extending
DefaultExceptionMapper because I wanted to follow an approach
comparable to the one discussed before:
http://apache-wicket.1842946.n4.nabble.com/Pass-exception-to-internal-error-page-td4664951.html
But DefaultExceptionMapper.internalMap is private and there's no other
callback to easily change the specific behavior I need.
> She doesn't know what is "null" and she doesn't want to know!
And that's perfectly OK, but in my opinion that shouldn't be a
decision made depending on Ajax vs. non-Ajax, and is in general highly
depending on the audience as well, which I know better than "Wicket".
So in the end, the only question is: Is it worth to make this specific
behavior of DefaultExceptionMapper a bit more flexible for users like
me or not? Given the two possible relative easy approaches, I think it
is worth it and hope that others will see it the same way.
https://issues.apache.org/jira/browse/WICKET-6158
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Provide error message for Ajax requests in DefaultExceptionMapper?
Posted by Martin Grigorov <mg...@apache.org>.
Hi Thorsten,
On Tue, May 3, 2016 at 3:19 PM, Thorsten Schöning <ts...@am-soft.de>
wrote:
> Guten Tag Martin Grigorov,
> am Dienstag, 3. Mai 2016 um 14:31 schrieben Sie:
>
> > Because the DefaultExceptionMapper is the final/catch-all place to catch
> > exceptions and it should be generic.
>
> Subclasses can't easily override this specific behavior as well and a
> more useful default behavior is generic.
>
Configuring your own IExceptionMapper is as easy as returning
MyOwnExceptionMapperProvider
from org.apache.wicket.Application#getExceptionMapperProvider.
But as I said earlier I'd recommend custom IRequestCycleListener instead!
>
> > Most of the time end users should not see what exactly broke in the
> > application. A generic "An error occurred" should be enough.
>
> Yeah, that's why the web is full of jokes and anger about no helpful
> error messages like that one. ;-)
>
How message like "Your request failed because the developer of this
application didn't check for null" could be useful to aunt Gertrude (a
regular user of your application) ?
She doesn't know what is "null" and she doesn't want to know!
Only developers care about the error (and make jokes about it)! And the
developers usually don't like to look at the server logs (me included).
Probably because they are afraid that they will find many more problems!
>
> Your argument doesn't even hold for your own codebase, like can be
>
It is not my own!
> seen in ServletWebRequest. In fact, it's the other way around: It is
> easy to not provide detailed information to my users if I/they don't
> want to, but it's unnecessary hard currently to do so if I/they want
> to know more.
>
As I said - DefaultExceptionMapper is a generic catch-all place. You should
not compare it to code specific to some use case.
>
> That's especially true for Ajax like in this case: Those errors are
> already either handled specially by the client software or simply
> ignored by the browser. So there's exactly no user out there getting
> to much unwanted information.
>
> > You could use custom IRequestCycleListener#onException() if you want
> > special behavior.
>
> I would prefer providing a patch making default Wicket implementations
> more useful for most devs and code base more consistent. ;-) You
> already have everything needed where it's needed and things could even
> be made configurable using some kind of INVOKE_FAILURE_HANDLER_WITH_MSG
> or a protected callback which creates the object to return with the
> current behavior as default implementation. I already have a subclass
> of DefaultExceptionMapper, it's only that I don't want to double so
> many code...
>
As you like to say: "Many developers don't like that there are multiple
ways to do the same thing. Which one is the correct?!".
Wicket documentation and dev team recommends
IRequestCycleListener#onException()!
I am not convinced but probably someone else will pick up your idea and
apply it ...
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
> AM-SoFT IT-Systeme http://www.AM-SoFT.de/
>
> Telefon...........05151- 9468- 55
> Fax...............05151- 9468- 88
> Mobil..............0178-8 9468- 04
>
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Provide error message for Ajax requests in DefaultExceptionMapper?
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Martin Grigorov,
am Dienstag, 3. Mai 2016 um 14:31 schrieben Sie:
> Because the DefaultExceptionMapper is the final/catch-all place to catch
> exceptions and it should be generic.
Subclasses can't easily override this specific behavior as well and a
more useful default behavior is generic.
> Most of the time end users should not see what exactly broke in the
> application. A generic "An error occurred" should be enough.
Yeah, that's why the web is full of jokes and anger about no helpful
error messages like that one. ;-)
Your argument doesn't even hold for your own codebase, like can be
seen in ServletWebRequest. In fact, it's the other way around: It is
easy to not provide detailed information to my users if I/they don't
want to, but it's unnecessary hard currently to do so if I/they want
to know more.
That's especially true for Ajax like in this case: Those errors are
already either handled specially by the client software or simply
ignored by the browser. So there's exactly no user out there getting
to much unwanted information.
> You could use custom IRequestCycleListener#onException() if you want
> special behavior.
I would prefer providing a patch making default Wicket implementations
more useful for most devs and code base more consistent. ;-) You
already have everything needed where it's needed and things could even
be made configurable using some kind of INVOKE_FAILURE_HANDLER_WITH_MSG
or a protected callback which creates the object to return with the
current behavior as default implementation. I already have a subclass
of DefaultExceptionMapper, it's only that I don't want to double so
many code...
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Provide error message for Ajax requests in DefaultExceptionMapper?
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Tue, May 3, 2016 at 2:22 PM, Thorsten Schöning <ts...@am-soft.de>
wrote:
> Hi all,
>
> > private IRequestHandler internalMap(Exception e)
> [...]
> > switch
> (application.getExceptionSettings().getAjaxErrorHandlingStrategy())
> > {
> > case INVOKE_FAILURE_HANDLER :
> > return new ErrorCodeRequestHandler(500);
> > }
>
> Is there any reason why the request handler doesn't get any message
> retrieved from the available exception? The exception message may span
>
Because the DefaultExceptionMapper is the final/catch-all place to catch
exceptions and it should be generic.
Most of the time end users should not see what exactly broke in the
application. A generic "An error occurred" should be enough. The exception
is logged in the server logs for the application developers.
You could use custom IRequestCycleListener#onException() if you want
special behavior.
> multiple lines and such of course, but such things could be filtered.
> Currently only getting 500 without any hint to what's actually wrong
> looks a bit wasteful.
>
> Especially if I see lines like the following in ServletWebRequest:
>
> > throw new
> AbortWithHttpErrorCodeException(HttpServletResponse.SC_BAD_REQUEST,
> > "Current ajax request is missing the base url header or parameter");
>
> So you already have places where you end with custom messages.
>
> Is this something worth filing as an enhancement in JIRA?
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
> AM-SoFT IT-Systeme http://www.AM-SoFT.de/
>
> Telefon...........05151- 9468- 55
> Fax...............05151- 9468- 88
> Mobil..............0178-8 9468- 04
>
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>