You write a reporting query, wrap it in try / catch so a bad query can never take down an AdminCP page, and ship it. The screen renders. The table is empty. You conclude there is no data yet.

There is data. The query is broken, and your own catch is what turned a fault into a plausible-looking zero.

The query

Db::i()->select(
    'conv_title, conv_url, conv_class, conv_item, COUNT(*) AS joined',
    'my_table',
    array( 'conv_item > 0' ),
    'joined DESC',
    25,
    array( 'conv_class', 'conv_item' )   // GROUP BY
);

MySQL 8 enables only_full_group_by by default and rejects it outright:

Expression #1 of SELECT list is not in GROUP BY clause and contains
nonaggregated column 'conv_title' which is not functionally dependent on
columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

Every column in the SELECT must either appear in the GROUP BY or be wrapped in an aggregate. "But every row in the group holds the same value" is true and irrelevant — MySQL will not take your word for it.

The fix

Aggregate the columns you are only carrying along. Over identical values, MAX() returns exactly those values:

'MAX(conv_title) AS conv_title, MAX(conv_url) AS conv_url,
 conv_class, conv_item, COUNT(*) AS joined'

Adding them to the GROUP BY instead also silences the error, but changes the meaning — you would then be grouping by title as well, and two items that happen to share a title would stop merging. Aggregate; do not widen the grouping.

Two things worth knowing about IPS's query builder

• A multi-column GROUP BY must be passed as an array. A comma-joined string is quoted as one identifier and the query fails.
• Db::insert()'s third argument is a boolean, and the ON DUPLICATE KEY UPDATE it generates is col=VALUES(col) — a replace. It cannot increment a counter. For a daily counter, use INSERT IGNORE (fourth argument TRUE) followed by Db::i()->update( $table, "col=col+1", $where ), which is what core itself does for hit counters.

The larger point: log what you swallow

Wrapping report queries in try / catch is correct — an analytics screen should not be able to break the AdminCP. But a bare catch around a query that returns a list is uniquely dangerous, because an empty list is a completely believable answer. "No page has ever produced a member" and "the query does not run" look identical on screen, and only one of them is worth investigating.

catch ( \Exception $e )
{
    Log::log( $e, 'myapp_report' );   // ← the difference between a
    return array();                   //   mystery and a stack trace
}

The rule generalises: swallow an exception only where the caller can tell the difference between "nothing" and "broken". Where it cannot — reports, lists, counts, dashboards — leave a trace in core_log. Otherwise the first person to notice will be a customer telling you the feature does not work, and you will have nothing to go on.

Test it with data, not on an empty install

An empty-install test passes happily here: the correct answer and the broken answer are both an empty array. Build a fixture with a known answer — three rows that must group into one with a count of three — and assert the count. That is the only version of this test that can fail.

Related: The ?: fallback silently breaks any setting an admin can set to zero, Db::insert() third and fourth arguments do very different things