i would hate a user to look at a signup form without a signup button because something inside it caused an error.
i would also hate to see a user at a checkout page with a missing $500.00 discount amount shown because there was an error in the discount label. showing a "mostly" constructed page does not sound like a good idea to me because you are opening pandora's box, unless of course, you can anticipate and account for all possible ways in which a page can break. but then again, like you said, as soon as you do it will find another unexpected way to break. -igor On Tue, Nov 4, 2008 at 11:19 AM, aditsu <[EMAIL PROTECTED]> wrote: > > > Alex Objelean wrote: >> >> Can you be more specific? What kind of unexpected runtime exceptions are >> you talking about? I don't think I understood you correctly. >> > > It could be anything.. NPE (probably the most popular), > IllegalArgumentException and its descendants, ArithmeticException, > ClassCastException, IndexOutOfBoundsException etc... or a wrapper for a > checked exception. > It can happen in the application code or can be thrown from library code. > As for the reasons.. again there are lots of possibilities: invalid input, > buggy code, invalid data received from 3rd party, unhandled edge case, > unavailable resource, high load, etc. > > > >> Any runtime exception thrown by the wicket is caused by a programming >> error... there is no sense to catch it without fixing the problem in your >> code. >> > > That sounds foolish to me, unless you consider any failure to handle any of > the situations described above, to be a programming error. > And I disagree a LOT more about the second sentence: usually when an > application is launched, it already passed some kind of testing which found > everything to be working well, and the application works well for a while, > then an unexpected exception happens. These exceptions in production are > very good friends of Murphy and tend to follow several laws, such as: > - Whatever can go wrong will go wrong, and at the worst possible time, in > the worst possible way > - Every non trivial program has at least one bug > - If you perceive that there are four possible ways in which something can > go wrong, and circumvent these, then a fifth way, unprepared for, will > promptly develop > - If the input editor has been designed to reject all bad input, an > ingenious idiot will discover a method to get bad data past it > So anyway, when (not if) the unexpected exception is thrown in production > code, what would you rather have the users see (whether there are 10, 1000 > or 10000000 users)? A big "internal error" page? Or a mostly-working page, > but with one part missing or showing an error message? Especially if access > to that same page is required in order to fix the problem! > -- > View this message in context: > http://www.nabble.com/Handling-exceptions-during-render-tp20301737p20327592.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
