Hello,
Davi Arnaut a écrit, Le 19.01.2011 20:08:
> On 1/19/11 4:58 PM, Guilhem Bichot wrote:
>> #At
>> file:///home/mysql_src/bzrrepos_new/mysql-next-mr-opt-backporting-wl4800/
>> based on revid:guilhem.bichot@stripped
>>
>> 3260 Guilhem Bichot 2011-01-19
>> todo question
>>
>> modified:
>> WL4800_TODO.txt
>> === modified file 'WL4800_TODO.txt'
>> --- a/WL4800_TODO.txt 2011-01-17 20:41:34 +0000
>> +++ b/WL4800_TODO.txt 2011-01-19 18:58:53 +0000
>> @@ -44,3 +44,7 @@ Make --opt-trace-protocol dump traces to
>> can run with it without failing all tests.
>>
>> Update copyright header of all changed files to reflect changed in 2011
>> +
>> +should the debug binary really assert(0) if json syntax error? is it a
>> +good idea at the customer's? On the other hand, how to make sure a
>> +developer notices a syntax error when running tests?
>>
>
> Perhaps it is time for us to have a DEBUG_WARN?
What would this macro do?
The context is that if a customer/support is troubleshooting a
problematic query, using the optimizer trace and a debug binary, it may
happen that she/he hits a case where the trace is not JSON-compliant
(we, optimizer team, cannot guarantee that we have studied *all* code
paths which can lead to generation of a trace; there are many more than
what is exercised by the full mtr testsuite).
In that case, for the customer, the invalid-syntax trace is still worth
looking at, informative, and a DBUG_ASSERT(0) is then a pure annoyance.
On the other hand, when I, developer, am modifying the optimizer and
running the testsuite, I certainly want to be told if my changes lead to
an invalid trace, and for this, DBUG_ASSERT(0) is perfect (it makes the
test fail).
Maybe we could do a sql_print_warning() instead of DBUG_ASSERT(0); mtr
warns when it sees an unexpected warning, it marks the test as failed,
prints the warning on stderr, and returns 1 as exit code. I guess this
would be good enough?
