> ti 11. lokak. 2022 klo 11.12 Korbinian Bachl (korbinian.ba...@whiskyworld.de) > kirjoitti: > >> >> > >> > It is your application so you must know/design how to recover from the >> > error. You either re-render the same page or redirect the user to a >> > suitable error page. >> > >> > ** >> > Martin >> > >> >> Thats exactly the misunderstanding. If one of 100s of components fails - >> not even necessarily "made" by myself (.g.: some null pointer down the >> drain of a Panel) - why should the whole rest of the page fail, too? >> Why should we redirect and not just ignore the single root cause (a "bad" >> component/ panel) silently? >> >> I mean, most of errors that occur in Prod for us are because something >> happens that was never meant to be. Be it that backend data came in that >> violated the contract (because of update of a third party service without >> notice / or in error) or something else that is not know in advance. >> >> Point is: if a page consists of 1000 Components and only 1 of it fails: >> why has this single point of failure the need to take down the rest of the >> page? >> > > I think you should think of it like a transaction. A well designed page is > like a transaction. If there is a fault, it should rollback everything. > Otherwise, you need to design very carefully which faults you want to allow > and which ones not. A quick-and-dirty way is to add catches to the sub > panel rendering phases so that they don't care about the faults, but you > will run a risk that your user is not getting consistent information. This > might be a problem or it might not be. > > Also, if you have lots of these, you probably have some sort of systematic > design flaw in your application, try to debug heuristically it and solve it. > > In my experience, the only situations where exceptions are "normal" in > wicket is when there is some kind of invalid session and parts of the page > attempt rendering while some other parts fail to render, and the correct > action in such case is to discard rendering and redirect to login. > > But your case might be different and you need to investigate the root > cause. Otherwise you run risk of steering your product like a lost ship on > the vast ocean with some unexpected harm ahead. > > To summarize, unexpected exceptions in wicket are not normal, you should > not allow them. > > ** > Martin
I understand your point of view while not sure this is the correct interpretion to see a page as a "transaction". If there are forms, maybe you can see it that way but a page is usually a way to present information/ data. I had some time to work with RoR lately and the way it evolved in the last years and also solved many problems with clever convention over configuration let me rethink some of my previous ways. Also backend frameworks like e.g. micronaut have baked in things like retryable or CircuitBreaker because they just *expect* it that something will fail anytime anyhow. In our prod app we got a 500 because of a dumb null pointer that happend because of a rare race condition depending on the backend... something that was clearly a fault initially but only with the current way to fail the whole page made it a problem. The idea is just to not fail a whole page but only the part of the page that fails - while logging in the backend so that the usage of the page is not 0 but maybe still 80% And from my experience I never expect my code to not have bugs in it, so it will fail at some point. I mean, why do we have so many regular wicket releases if its bug free? ;) PS: can you elaborate how to globally alter the sub panel phases?
