And on that note, why does PageParameters throw all those checked
exceptions? Is there really anything I can do about it on the page
itself?
On 8/6/05, Phil Kulak <[EMAIL PROTECTED]> wrote:
> I'm happy with anyway that I can get to an exception that I throw at a
> place where I can do something about it. For example: say I have a
> bookmarkable page that takes an id. What if someone submits an id that
> doesn't exist anymore? I need to throw an exception becuase the page
> can't be built without that information, and if I don't build it, I'll
> get a component-not-found exception. So I throw an
> WebInterfaceException with a nice error message, but all the user sees
> is a stacktrace. If I could get at the error somewhere up the stack
> and tell the user exactly what happened, all would be well.
>
> And this use case is NOT using exceptions for control flow. All
> exceptions are not by definition non-recoverable. The point is to be
> able to recover from them, otherwise they may as well not exist.
> Having the program just crash all the time would accomplish the same
> ends.
>
> On 8/4/05, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > are you replying to me? (i already pointed that out that you want
> > something if you make youre own InternalErrorPage)
> > The default internalerror page that is uses as an exceptionpage that is
> > displayed in deployment mode is right by the way.
> > You shouldn't give any stacktraces back to the world when deployed. Then
> > you are giving to much info.
> > That kind of stacktraces should only be logged and then looked up by the
> > developer when a user is saying i get
> > and error page and this was on them (just a code or something where the
> > developer knows where to look for
> > so that he knows what is going wrong)
> >
> > So i vote for letting the ExceptionPage page be what it is . IT is just
> > for development mode and i think that is ok.
> > Lot's of info for the developer. If you have any comments about it like
> > i want that or not that then please open a bug report.
> >
> > But for the internal error page the the developer can set we still need
> > a solution to get the exception into that page
> > so that the developer can do something with it (it can display the
> > exception in the page if he wants but that won't be
> > the default of wicket).
> >
> > So i can introduce this interface:
> >
> > InternalErrorPage
> > {
> > setThrowable(Throwable)
> > }
> >
> > or i can look for a constructor at runtime and if you made a constructor
> > like this:
> >
> > MyErrorPage(Throwable t)
> >
> > then i will call that one.
> >
> > So please tell me what you guys find best. Or do you have another solution?
> >
> > johan
> >
> >
> > Phil Kulak wrote:
> > > The whole point of exceptions are so that you know what happened.
> > > What's the point of going to all that trouble to pass it all the way
> > > up to the top of your app, and then drop it on the floor at the very
> > > last step, right before something useful could actually be done with
> > > it?
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > > Practices
> > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> > > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> > > _______________________________________________
> > > Wicket-user mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/wicket-user
> > >
> > >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Wicket-develop mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
