Consistency in return values

Rà soát toàn bộ class, đặc biệt là các phương thức tìm kiếm và duyệt, rồi so sánh các giá trị trả về hiện tại của chúng với các phương thức báo lỗi được mô tả trong issue. Trước hết, hãy thống nhất một hợp đồng phản hồi duy nhất; được xem là hoàn tất khi tất cả các phương thức bị ảnh hưởng đều tuân theo hợp đồng đó một cách nhất quán mà không để ngỏ quyết định về khả năng tương thích.

During my recent implementations and rewrites, I've introduced some "error reporting" to make it easier for the caller to figure if and what might have gone wrong. On error, several methods now return an array like

[success:0, message:"reason"]

But not all of them – for example, most of the search/browse methods supposed to return a simple array of package names don't have this. There would be two options to reach (a sort of) consistency:

• returning [success:0, message:reason] instead (and if so, include success:1 with a "good result) also for those methods that currently do not, moving the "real results" into a "sub-array" (which then, on error, could be empty or just not present at all)
• simply returning an empty array, and have a getLastError() method for obtaining the reason for all search/browse methods while keeping the current behavior for the others.

I'd prefer the first approach (so it's completely consistent) with the "empty real result". This combines the best of two worlds, e.g.

$apps = $google->parseWhatever();
if ( empty($apps['data']) ) { // this could simply mean nothing found matching the criteria
  if ( $apps['success'] ) { log('nothing found'); }
  else { log ('ERROR occured: '.$apps['message']); }
} else { // do something with the data

I'd even go as far as to always include the message key, just leaving its value empty on success. That would make things most consistent.

What's your stance? If you agree, I'd go over the entire class another time and make it consistent:

• success:0 only on errors – not generally on "no results" for a user-specified search (I vaguely remember I accidentally made it such in one case). message then holds the reason (e.g. the HTTP response, or parse error when an expected pattern didn't match, etc)
• success:1 on success. message then is present but usually empty, but might eg hold a hint on why the result set is empty (like "no hits").

If we want to fix it, we want to do that as early as possible – before there are users whose code would otherwise break on some update.