Re: [gnulib-tool-py] func_warning

[Bruno Haible]

Hi Dmitriy,

> I suggest to rename GLError to GLErrorHandler to raise Pythonic errors.
> GLError now becomes a class

Hmm, 2 classes for a simple concept? Sounds a bit like overkill.
I'd prefer to continue to have 1 class only.

> 3. fatal: True or False. Default is True. Non-fatal error means that this
> is just a warning.
> 4. style: 0 or 1. 0 means old gnulib-tool style, 1 means that Pythonic error
> is raised using GLErrorHandler. Default is 0.

This would revert the good design that you have made earlier.

Remember the essential concepts of exceptions in Python:
  * The code that signals an exception passes information about _what_
    happened.
  * The handlers (try/except clauses) specify _how_ to handle them.
These two codes are located in different places; this is very important
for future flexibility.

A boolean 'fatal' would encode the _how_ in the code that signals an exception.
Not good.

Instead, my vote is to
  - Keep the design of GLError as it is, but with additional choices
    ("nonexistent module", "missing license", "duplicated dependencies",
     "incompatible license", etc.),

  - Create a variable 'globalHandler' which is a lambda, taking a lambda():void
    as argument, that executes its argument with some exception handling.
    The default would be to catch exceptions of type
      "nonexistent module", "missing license", "duplicated dependencies",
      "incompatible license", etc.
    but to not catch (or re-throw) exceptions of type
      "file does not exist", "missing sourcebase argument", etc.

    Code that wants to turn some of the warnings into errors will install
    a different globalHandler.

  - Use a commodity function that invokes globalHandler, passing it a
    lambda that throws a given exception.

I'm not familiar with Python lambdas and function types; you can fill in
this detail better than me.

Bruno