> It sounds like your complaint isn't with the advice from the book, but rather that Apple didn't follow it. They did hide away the error messages, but they didn't provide help and insight.
> If they had done so, you'd have (presumably) been told in the software that there was a problem with certain albums, and been walked through a flow that would fix said problem. Or maybe a link to a support page that'd do the same. This, if it was done, would have been much better than showing "error 0xFHJAD1234".
The parent post addresses this: there are so many ways for for the system to fail that it’s not feasible to “inventory every possible problem in a computerized system and then provide a graceful exit”. So where an error is not gracefully handled, the system should allow for a human to see the error and solve the problem, rather than throw away the error.
>> Without any false modesty, I think I have a fairly good idea of how modern computer architecture works. Yet, I will be the first to tell you that I have no idea how any of these systems work in full. In fact, no one does. Not the best of kernel developers nor the best of chip designers. To claim that you can somehow inventory every possible problem in a computerized system and then provide a graceful exit from that or useful info is either ignorant or arrogant or both. But since you've eliminated engineers from the design loop (see #1 above), no one will tell you you're full of it.
> The parent post addresses this: there are so many ways for for the system to fail that it’s not feasible to “inventory every possible problem in a computerized system and then provide a graceful exit”. So where an error is not gracefully handled, the system should allow for a human to see the error and solve the problem, rather than throw away the error.
Yes, that's what I said as well. It's why I said the problem was that Apple didn't follow the book's advice, insofar as they removed error messages without providing help for them... and so it's unfair for the grandparent-comment to blame the book when its rule wasn't followed.
It's definitely fair to blame the book when the book gives advice that is impossible to follow.
If it's not possible to always give help and advice, sometimes you have to give an error message and unless the book mentions that then it is definitely fair to blame the book.
Eh, I read the book as presenting a maximalist vision: in a perfect world, all error messages would instead be help that lets you resolve your issue.
Since it says to hide error messages and instead provide help, anyone who hides error messages and doesn't provide help can't really be said to be following the book's advice. It feels wrong to me to blame the book for not, in every bit of advice it offers, saying "don't half-ass this incorrectly". That seems inherent to me.
It's not a very useful book if it doesn't provide advice that works in the real world. I have not read the book - does it give advice on what to do if it's not possible to give help? Or does it just assume that it's always possible to be perfect?
In Ye Olde Dayes, Macs would in fact give you messages like "error 39!" when something went wrong. Only, in those days, there was almost no way to figure out what that meant.
> If they had done so, you'd have (presumably) been told in the software that there was a problem with certain albums, and been walked through a flow that would fix said problem. Or maybe a link to a support page that'd do the same. This, if it was done, would have been much better than showing "error 0xFHJAD1234".
The parent post addresses this: there are so many ways for for the system to fail that it’s not feasible to “inventory every possible problem in a computerized system and then provide a graceful exit”. So where an error is not gracefully handled, the system should allow for a human to see the error and solve the problem, rather than throw away the error.
>> Without any false modesty, I think I have a fairly good idea of how modern computer architecture works. Yet, I will be the first to tell you that I have no idea how any of these systems work in full. In fact, no one does. Not the best of kernel developers nor the best of chip designers. To claim that you can somehow inventory every possible problem in a computerized system and then provide a graceful exit from that or useful info is either ignorant or arrogant or both. But since you've eliminated engineers from the design loop (see #1 above), no one will tell you you're full of it.