MWExceptionHandler::handleFatalError() is installed as a shutdown
function to inspect `error_get_last()` output and log the error via
MWExceptionHandler::logError(). The error is examined to determine if it
is a missing class error so that a descriptive log message can be
provided instructing the server administrator on 3rd party library
installation methods.
Bug: T74777
Change-Id: I04748626487022c51050ffa7846236947a082d68
Follows-up 399ba2fecf which didn't include any translation of the error
type in the logged message (e.g. "PHP Notice" or "PHP Warning").
Before
Error from line 2130 of mediawiki/includes/OutputPage.php: Undefined variable: bar
Error from line 2130 of mediawiki/includes/OutputPage.php: strpos() expects at le..
After
Error from line 2130 of mediawiki/includes/OutputPage.php: PHP Notice: Undefined variable: bar
Error from line 2130 of mediawiki/includes/OutputPage.php: PHP Warning: strpos() expects at le..
Based on the log formatter in php
https://github.com/php/php-src/blob/0f5858e3a328/main/main.c#L1086-L1119
Change-Id: I52f98e52caa64955050ed73e1acbc78b1116a9fd
* Remove use of 'error' where it's redundant.
* Remove call to logException from responsibility of MWException.
Call from exception handler instead.
Change-Id: I8764cf5df87b226813c9b9cf99f9b4f3fa4b7c92
Previously, non-MediaWiki exceptions were logged only for api requests,
job runner, resource loader, etc. but not for general requests
such as page views.
Bug: 61914
Change-Id: Id4de5cac0b9996a98cdaf5e73655d49fa55ea8c3
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Change-Id: I8c9f30128b46086064326708a4878228ba459447
One of the causes (if not the cause) of bug 56269 is if something
manages to throw an exception that makes it to MediaWiki::run's
last-resort exception catcher while having an open database transaction:
the transaction never gets committed or rolled back, so it gets
implicitly rolled back and a warning is raised.
The API has the opposite problem in bug 63145: it catches the exception
but then does the normal DB shutdown which *commits* the transaction.
This is certainly the Wrong Thing to do.
Ideally, neither of these would ever happen because any code using
transactions would have its own try-catch that would catch any
exception, rollback the transaction, and then rethrow the exception. But
it happens anyway, so let's have both of these last-resort exception
handlers do the rollback, and also log the exception so the throwing
code has a better chance of being properly fixed.
Bug: 56269
Bug: 63145
Change-Id: I8f1da51187b281fe4afc0d5a0c49f5caf3612e92
