* BALATON Zoltan ([email protected]) wrote: > On Sat, 22 Nov 2025, Markus Armbruster wrote: > > "Dr. David Alan Gilbert" <[email protected]> writes: > > > > > * Markus Armbruster ([email protected]) wrote: > > > > "Dr. David Alan Gilbert" <[email protected]> writes: > > > > > > > > > * Markus Armbruster ([email protected]) wrote: > > > > > > Replace > > > > > > > > > > > > error_setg_errno(errp, errno, MSG, FNAME); > > > > > > > > > > > > by > > > > > > > > > > > > error_setg_file_open(errp, errno, FNAME); > > > > > > > > > > > > where MSG is "Could not open '%s'" or similar. > > > > > > > > > > > > Also replace equivalent uses of error_setg(). > > > > > > > > > > > > A few messages lose prefixes ("net dump: ", "SEV: ", __func__ ": "). > > > > > > We could put them back with error_prepend(). Not worth the bother. > > > > > > > > > > Yeh, I guess you could just do it with another macro using > > > > > the same internal function just with string concatenation. > > > > > > > > I'm no fan of such prefixes. A sign of developers not caring enough to > > > > craft a good error message for *users*. *Especially* in the case of > > > > __func__. > > > > > > > > The error messages changes in question are: > > > > > > > > net dump: can't open DUMP-FILE: REASON > > > > Could not open 'DUMP-FILE': REASON > > > > > > > > SEV: Failed to open SEV-DEVICE: REASON > > > > Could not open 'SEV-DEVICE': REASON > > > > > > > > sev_common_kvm_init: Failed to open SEV_DEVICE 'REASON' > > > > Could not open 'SEV-DEVICE': REASON > > > > > > > > I think these are all improvements, and the loss of the prefix is fine. > > > > > > Yeh, although I find the error messages aren't just for users; > > > they're often for the first dev to see it to guess which other > > > dev to pass the problem to, so a hint about where it's coming > > > from can be useful. > > > > I agree! But I think an error message must be make sense to users > > *first* and help developers second, and once they make sense to users, > > they're often good enough for developers. > > > > The common failures I see happen when developers remain caught in the > > developer's perspective, and write something that makes sense to *them*. > > Strawman form: > > > > prefix: failed op[: reason] > > > > where "prefix" is a subsystem tag, or even __func__, and "reason" is > > strerror() or similar. > > > > To users, this tends to read as > > > > gobbledygook: techbabble[: reason] > > > > When we care to replace "failed op" (developer's perspective) by > > something that actually makes sense to users, "prefix" often becomes > > redundant. > > > > The error messages shown above aren't bad to begin with. "failed to > > open FILE", where FILE is something the user specified, should make > > sense to the user. It should also be good enough for developers even > > without a prefix: connecting trouble with the DUMP-FILE to dump / > > trouble with the SEV-DEVICE to SEV should be straightforward. > > > > [...] > > I think that > > net dump: can't open random-filename: because of some error > > shows better where to look for the problem than just > > Could not open 'random-filename': because of some error > > as the latter does not tell where the file name comes from or what is it. It > could be added by a management application or added by the users randomly > without really knowing what they are doing so repeating the option or part > in the message that the error comes from can help to find out where to > correct it. Otherwise it might be difficult to guess what random-filename is > related to if it's not named something you'd expect.
Yeh agreed. It very much depends if you think of a 'user' as the person who typed a qemu command line, or pressed a button on a GUI that triggered 15 levels of abstraction that eventually ran a qemu. Or for the support person who has a customer saying 'help I've got this error', and now needs to route it to the network person rather than something else. Dave > Regards, > BALATON Zoltan -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ \ dave @ treblig.org | | In Hex / \ _________________________|_____ http://www.treblig.org |_______/
