Why doesn't WP_List_Table implement column_cb() and column_default() ?

[bobbingwide]

I know that WP_List_Table is reserved for WordPress core, so I took a copy as suggested. Then I starting writing my own code to use the new class.

I sort of followed the step by step guide in ​http://wpengineer.com/2426/wp_list_table-a-step-by-step-guide/ but got ahead of it and defined some columns without implementing any logic to display them.

When executed all I got was "No data received" (in chrome ).

I was hoping that I might have at least found a "Fatal error: call to undefined method class::method" somewhere in my error logs.

Am I doing something terribly wrong?
My workaround is to implement die()ing methods in the parent class.
Is there any reason why the same solution should not be applied to the core code?

[bobbingwide]

Further investigation reveals the follow message from the Apache error log
[Fri Nov 07 08:42:55.006465 2014] [mpm_winnt:notice] [pid 1868:tid 600] AH00428: Parent: child process 3652 exited with status 322122
5725 -- Restarting.

I tried increasing the ThreadStackSize to 8M, then to 16M, but to no avail.
In other classes I have no problem getting PHP to report the fatal error.

[helen]

Not really following what the specific bug is here - if this is a question, please try the support forums instead.

[afercia]

No reporter feedback in 9 months and looks like something more appropriate for the support forums. I'd propose to close this ticket if no objections.

[SergeyBiryukov]

Replying to bobbingwide:

I sort of followed the step by step guide in ​http://wpengineer.com/2426/wp_list_table-a-step-by-step-guide/ but got ahead of it and defined some columns without implementing any logic to display them.

Could you provide a piece of code to reproduce the issue?

[bobbingwide]

WP_List_Table was updated in 4.3, so the behaviour that I was experiencing has now changed.
I have updated my forked/cloned code to reflect the new logic.

I'll have to see if the same or similar problem exists in 4.4