Re: Provide error message for Ajax requests in DefaultExceptionMapper?
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.schoen...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Provide error message for Ajax requests in DefaultExceptionMapper?
Hi Thorsten, On Tue, May 3, 2016 at 3:19 PM, Thorsten Schöning 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.schoen...@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-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Provide error message for Ajax requests in DefaultExceptionMapper?
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.schoen...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Provide error message for Ajax requests in DefaultExceptionMapper?
Hi, On Tue, May 3, 2016 at 2:22 PM, Thorsten Schöning 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.schoen...@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-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
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.schoen...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org