----- Ursprüngliche Mail -----
>
> If you are ok with a 80% failing page, I cannot help you, because in that
> case you can simply come up with another fallback which works 80%. You know
> this leads/creeps to exponential growth of failures and work, yes?
>
> The right way to handle it is to inform the user that something has failed,
> suggest the user to retry (or you can retry once programmatically if you
> think the problem is rare).
>
> And receive alerts from such problems in production and find the root cause
> and fix it, for example by fixing a race condition issue by adding blocking
> queues or whatever best suits your use case.
Well, for me the thing is: if the whole page fails you need to fix it asap - if
only 10% of the page fails you could ignore it some time and have it fixed at a
later point in time when you have resources
free.
I see this as a pure business administration problem: save money if possible...
I know this is not something a programmer likes but nobody of us programms for
free :)
>
> 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? ;)
>>
>
> Is not about being bug free, but how to respond to bugs and how to curb
> bugs and how to curb the impact of bugs.
Right: have a way to ignore it a maximum amount of time till you fix it...
based on the impact of the bug itself.
In case the bug takes down everything you need to fix it asap. If it takes down
only a part: depending on the part itself you react...
