Hi Thorsten, On Tue, May 3, 2016 at 3:19 PM, Thorsten Schöning <tschoen...@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.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 > >
