[suggestion snipped]
> The whole concept would allow for:
> 1. getting many more very happy users.
> 2. *much* improved error handling/details.
> 3. a job (documenting error messages) for not-so-experienced
> developers
> (i.e. experienced Wine users)
> 4. reducing Wine size.
First of all I agree with Dimitrie. Your suggested solution,
at least syntactically, does not get my approval either.
However syntax is one thing and semantics is quite another
thing. Syntax can be checked with for exampel my winapi_check.
In fact it already do simple checks of the debug messages,
eventhough they are currently turned off by default since there
are to many reported errors.
Syntax is probably the least of our problems.
The real problem is IF we should report an
"error" to the user.
Notice I write "error". This is because not all errors are
real errors. Since you commented the discussition between
me and Alexandre about passing NULL valus to the functions,
I will not reiterate to much of that disussion, other
than to remind that there might be application that uses
the fact the most Windows API:s doesn't crash on NULL
values and that there is rational reason for doing so,
among other things it speed up the fast path (everythings
works) at the expense of the slow path (something fails).
The question whether it a good programming style to do that
or not (Alexandre claims it isn't, I'm not at all that certain)
is irrelevate. The fact is that some people do that since it is
supported. Note that it might not be of choice but simple because
their application works according to specification even if something
fails. "If it ain't broken don't fix it".
Of course NULL values is not the only is this a real error
problem just one of many.
The point is that until we decide "What is an error and what
is not?" the whole "What syntax should be used?" discussion
is rather meaningless.
Of course in general the problem is undecidable, it isn't
possible to know, no matter what methods we use.
So I think that we must instead ask the question:
"What methods should we use to find the existing
bugs in Wine?" Trying to reduce the problem to
"How should our error messages look like?" is
not doable.
So what should we do? See separate mail.
> After all we're *not* Microsoft ! We really should be able to
> do better
> than them and *document* our errors as soon as they occur.
[snip]
> And YES, we should do this or a slightly altered concept NOW !
I agree, but the problem is a lot more complicated than meets the
eye at first.
