> at least show a sensible error message so people who haven't spent ridiculous amounts of time reading the source code of your product as part of their job can troubleshoot their systems. Not "something failed, go read logcat, maybe it helps, good luck".
While I’m not sure whether it’s true, I think the reasoning behind this is that to the average user, a sensible error message is about as useful as "something failed, good luck".
An infinite loop as you described however is not really an error condition; in fact this is the premise of the Halting Problem [1] which is not solvable as far as we know. There's no way for the media provider to know if the loop will ever resolve and it may just be the case that you have an absolutely massive photo library that takes a lot of time to load. You could argue that they could add some sort of background timer that triggers an error if the provider takes too long to deliver data, but then what should that timeout be? What if the user's device is just naturally slow or the photo library is stored on some sort of external storage device (SD card maybe) with awful bandwidth? If your timeout is too low, it will prevent users from legitimately accessing their photo library; if it's too high, it ruins the point of having a timeout in the first place.
In this sort of scenario the better choice rather than implementing error detection is just fixing the original problem that caused an infinite loop so users don't need to fix anything in the first place. I think the reason why debugging/resolving issues seems so complicated in modern times is in part because we already did fix most/all the "easy" issues from the past generation -- the only remaining issues are extremely hard to catch or, in the case of the Halting Problem you experienced, mathematically impossible.
> In this sort of scenario the better choice rather than implementing error detection is just fixing the original problem that caused an infinite loop so users don't need to fix anything in the first place.
Sure, not having the bug would be better, but I can only assume that the developers didn't intend to make the conversion loop. They failed to not have the bug then, and most likely will fail to not have bugs in the future; that's life. The solution in this case may not be to detect an error condition, but to just indicate what the software is doing. Ex a persistent notification for 'updating database schema', maybe appearing after a 5 minute timeout; if that sits around for an hour or five days or something, you can google around for it.
While I’m not sure whether it’s true, I think the reasoning behind this is that to the average user, a sensible error message is about as useful as "something failed, good luck".