Want quick answers? Ask questions well

Re:Want quick answers? Ask questions well by 9dev on Wednesday August 31, 2022 @05:40PM (#32668725)

Weeeelp… I See both sides of this. There’s some things you anticipate to go wrong, like a disk being out of space, or an API to not respond. Those are the type of things you can (and should strive to!) provide meaningful error messages for.

But then, there’s also that class of things that fail in exciting and unexpected ways: a bit randomly flipping in memory, a cable detached in an untimely moment, a missing system library that was there when the program started… you cannot enumerate all things that may fail unexpectedly, hence the only viable solution is to have a special case for those - „Unexpected error“ doesn’t sound wrong from that perspective.

Still, it’s completely useless to the human in front of the machine, so there’s that.

[ Parent | on HN ]

Re:Want quick answers? Ask questions well by funcDropShadow on Friday September 02, 2022 @06:09AM (#32688867)

In such cases the dialog box could at least have a button "Show details" which provides the technical error message or code and some context, such that an advanced user has a chance to fix it. To the average noob this will make no difference, therefore A/B testing will select against it. But all the advanced users, admin will keep being infuriated.

The useless error messages are still my number one reason to avoid anything from Microsoft.

[ Parent | on HN ]