List:Backup« Previous MessageNext Message »
From:Ingo Strüwing Date:October 27 2009 4:39pm
Subject:Re: RFC: WL#5046 - error reporting
View as plain text  
Hi Rafal,

Rafal Somla, 27.10.2009 10:08:

> Ingo Strüwing wrote:
>> Rafal Somla, 24.10.2009 16:02:
> But, do you have any concrete propositions what error situations for
> which services should be distinguishable (across all BSMs)? Or you are
> only concerned with possible future extensions?

I am concerned about human fallibility. Often during implementation or
changes (e.g. bug fixes) problems pop up, which haven't been foreseen
during specification.

Hence I'm not in favor of an interface specification, which requires all
(if only non-fatal) problems to be identified in advance.

If we want to specify all behavioral aspects, it might be easier to
adapt the specification to reality by changing a list of error codes
than by changing a service signature.

We can leave it to the backup kernel, which errors to take as fatal, and
which to work around. Backup kernel could be fixed in this respect,
without changing the interface.

>>> There is no global convention about which error number means what.
>> This is something, which might bite us one day. If multiple modules
>> report similar error messages for problems that are pretty different to
>> handle by the user, then the support team might have a hard time to
>> figure out, what happened exactly. Sure, the final message contains the
>> module name, but often the customer doesn't remember the exact text.
>> Especially if he is no native English speaker. "The backup said no such
>> tape", but it was "file not found". Perhaps the xbsa: type specifier had
>> been forgotten. A globally unique error number would help a lot.
> I don't understand the example. How "The backup said no such tape" could
> possibly appear if we are using a filesystem BSM and the real problem
> was "file not found"?

By plain user error. Users don't read error messages carefully.
Especially if they don't understand the language well. To the example:
User wants to restore from tape. He forgets xbsa:. Error message is
"file not found". User identifies the words "not found". From his school
English he understands it as "not there". But the tape is there! So
what's wrong? Let's call support and tell them MySQL is stupid. It
claims "tape not there", while it is there.

The user would do better, if the message was in his native language.

Support would have better chances if there is a unique error number.
Some (management-)applications could also profit from unique error
numbers. So they won't need to parse the error text.

>>     There
>> should be a way to handle internationalization for storage modules.
> Easier said than done :) Any propositions? If the proposition is that
> BSMs use my_error() to report errors then I will oppose such solution...

See for example:
WL#2940 - plugin service: error reporting
WL#751 - Error message construction

But I must admit that this is not solved for us yet. We may not want to
spend the effort at the moment. So I will not further insist in
internationalized messaged from storage modules for now, but I want to
have the interface specified so that it can be added later without an
interface change. This might be doable when the plugin services (here
WL#2940) are implemented. You have already suggested a way to select the


Ingo Strüwing, Database Group
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schröder,   Wolfgang Engels,   Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring   HRB München 161028
RFC: WL#5046 - error reportingRafal Somla24 Oct
  • Re: RFC: WL#5046 - error reportingIngo Strüwing25 Oct
    • RE: RFC: WL#5046 - error reportingAndreas Almroth26 Oct
    • Re: RFC: WL#5046 - error reportingRafal Somla27 Oct
      • Re: RFC: WL#5046 - error reportingIngo Strüwing27 Oct
        • Re: RFC: WL#5046 - error reportingRafal Somla28 Oct
          • Re: RFC: WL#5046 - error reportingIngo Strüwing29 Oct
            • Re: RFC: WL#5046 - error reportingRafal Somla3 Nov
              • RE: RFC: WL#5046 - error reportingAndreas Almroth4 Nov
  • Re: RFC: WL#5046 - error reportingRafal Somla27 Oct
    • Re: RFC: WL#5046 - error reportingIngo Strüwing27 Oct
      • Re: RFC: WL#5046 - error reportingRafal Somla27 Oct
        • RE: RFC: WL#5046 - error reportingAndreas Almroth27 Oct
  • Re: RFC: WL#5046 - error reportingIngo Strüwing4 Nov