[rfc] handling warnings to users

Martin Pool mbp at canonical.com
Sun Aug 16 04:06:56 BST 2009


There are a few cases like warning about deprecated formats where we'd
like to display a kind of nag or warning message to the user, for
example about using an outdated format or they have uncommitted files
or an incompatible plugin.

Some specific cases could be handled differently, automatically or
without troubling the user, but I think there will still be some
cases.

At the moment they're handled in a somewhat ad-hoc way by either
writing to stderr or through bzrlib.trace or otherwise.  There's no
standard way to suppress them though some particular commands do have
options to do this.

We would like something which:
 * looks reasonably clean
 * can be suppressed if the user's decided it's not relevant; ideally
they would be able to suppress eg format warnings per-location
 * could be i18nized in qbzr or similar
 * can be tested
 * can be presented cleanly in a gui
 * can be passed across the network
 * is friendly to developers

I'd previously dismissed Python warnings as not being very helpful
because they seem very oriented towards warnings about the Python
code, rather than messages to the user: they're printed by default
only once per call site, and they include a code snippet.

However, it occurs to me that we could adapt them to work well:

 * add an "is an internal error" or not flag, as we have for other errors
 * for non-internal errors, print them every time they occur, and
print them with no code snippet
 * add a configuration variable to suppress warnings
 * possibly add a 'raise a warning about a specific url/branch' that
can check filters for that location (or they could just do it by
string matching.)
 * arrange for user warnings not to terminate the program even when
run with -Werror
 * add a warning subclass for each distinct case

This could be good because

 * it avoids duplication of code
 * avoids having two similar 'flag a warning' interfaces, in favor of
one interface handling different objects
 * we already have some test support for catching and examining warnings
 * they remain real objects while being raised therefore can be turned
into nice dialogs or whatever; you could even give the user the chance
to cancel the operation at this point

-- 
Martin <http://launchpad.net/~mbp/>



More information about the bazaar mailing list