Bruno Borges wrote:
> But, let's see your example:
>
> MyPage(PageParameters params) throws Exception {
> long id = params.getLong("id");
> ....
> }
>
> PS: and believe me, I faced a case like this yesterday!
Well, I'm not exactly making that up, I'm just trying to give feedback
based on practices to make the code easier and cleaner. There is nothing
worth than having copy/paste of error handling code and actually bad
code handling can make thing worse. Thus my preference for
runtimeexception to have fail-fast.
I have to check again but I remember also that putting some non-string
object in the PageParameters for BookmarkablePageLink can have thing
blow up later during rendering (have to doublecheck that assertion) and
the error message does not exactly help to find the root cause of it.
It might be an indication to do override valueMap.put() and do some type
checking upfront.
> In my case, the checked exception alerted me to display a nice and
> beautiful message saying: "stupid user, you sent an invalid ID and
> that's why I will not display a message with some stack trace so you
> don't have to botter, or worst: a message saying the object doesn't
> exist in the database."
The thing is that:
1) if the users messes with the parameters on the browser, then he has a
chance to come up with a 404 or 500 which can have very nice pages
follow by a redirect or similar.
2) if the user is actually input data which is used in the parameters
and that a certain type is expected. It is of course a programming error
not to check the type and a nice and helpful message should be sent to
the user indicating that he mistyped it and that an
integer|long|string|float... is expected. This is the validation part.
So it is a programmer responsability to check input data and validation.
> If it were unchecked and the project team wasn't expert within Wicket,
> we could get a lot of pages throwing exceptions in production and users
> calling the support to ask "Why?".
mm...
next question is (haven't looked at it yet). Can wicket handle exception
at a higher level with an exception handler ?
As a last resort your servlet container can handles exception quite well
at the webapp level for critical error codes. This should not be
underestimated, stupid examples below:
<error-page>
<exception-type>javax.sql.SQLException</exception-type>
<location>/database_problem.jsp</location>
</error-page>
<error-page>
<error-code>500</error-code>
<location>/oops_sorry_there_something_wrong_with_us.jsp</location>
</error-page>
Note however that as MSIE decides to display his own error pages when he
receives a http error code in the response (unless you unchecked 'Show
friendly HTTP error messages' in the options) then you will never see
that beautiful error page, so you have to workaround that by sending
back a http 200 so that it displays you page. (If i remember well it
also depends on the amount of data in your page, if over 512 bytes your
page will be displayed rather than the default MSIE one)
> Anyway, that's my opinion... :D
I respect that. :)
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
