[TYPO3-core] Fix for "debug_check_recordset" in t3lib_db

[Dmitry Dulepov [typo3]]

Hi!

Martin Kutschker wrote:
> Right. I was speaking against Bernahrd's argument that the "user" is 
> used to the PHP warnings. It's debatable whether 
> t3lib_db::sql_fetch_assoc() should do an input argument checking. But if 
> it doesn't it shouldn't let any functions it calls "pollute" the script 
> output.

I agree. Fortunately mysql_fetch_assoc() will report errors only if $res 
is incorrect. This may happen only and only if developer did not bother 
to check results of previous SELECT query. Since this is a serious bug I 
think we can let this function shout even to user and show full stack 
trace because such errors are hard to catch. In fact I propsed this 
function (yes, it was I) because I had a problem with core that it 
randomly showed errors from mysql_fetch_assoc and I could not catch it 
without stack trace.

It is like having water leak alarm or fire alarm in home. It will not 
stop a leak or fire but at least it will warn you that something went 
really wrong. Hopefully it will never shout but better to have extra 
precaution.

>> No need. mysql_fetch_assoc does this and you will see it if 
>> error_reporting is enabled. But if it is disabled, your trigger_error 
>> will not be visible anyway. Existing solution works even if 
>> error_reporting is disabled.
> 
> Why? I can use @ for mysql_fetch_assoc.

What is the point of your trigger_error than? :) You mask one error 
message in favor of your own?

-- 
Dmitry Dulepov
TYPO3 freelancer / TYPO3 core team member
Web: http://typo3bloke.net/
Skype: callto:liels_bugs