ca71e69fc6
Don't catch and discard exceptions from the RequestTimeout library, except when the exception is properly handled and the code seems to be trying to wrap things up. In most cases the exception is rethrown. Ideally it should instead be done by narrowing the catch, and this was feasible in a few cases. But sometimes the exception being caught is an instance of the base class (notably DateTime::__construct()). Often Exception is the root of the hierarchy of exceptions being thrown and so is the obvious catch-all. Notes on specific callers: * In the case of ResourceLoader::respond(), exceptions were caught for API correctness, but processing continued. I added an outer try block for timeout handling so that termination would be more prompt. * In LCStoreCDB the Exception being caught was Cdb\Exception not \Exception. I added an alias to avoid confusion. * In ImageGallery I added a special exception class. * In Message::__toString() the rationale for catching disappears in PHP 7.4.0+, so I added a PHP version check. * In PoolCounterRedis, let the shutdown function do its thing, but rethrow the exception for logging. Change-Id: I4c3770b9efc76a1ce42ed9f59329c36de04d657c |
||
|---|---|---|
| .. | ||
| Hook | ||
| BlobAccessException.php | ||
| BlobStore.php | ||
| BlobStoreFactory.php | ||
| DerivedPageDataUpdater.php | ||
| EditResult.php | ||
| EditResultBuilder.php | ||
| EditResultCache.php | ||
| NameTableAccessException.php | ||
| NameTableStore.php | ||
| NameTableStoreFactory.php | ||
| PageEditStash.php | ||
| PageUpdateException.php | ||
| PageUpdater.php | ||
| PageUpdaterFactory.php | ||
| PreparedUpdate.php | ||
| RevertedTagUpdate.php | ||
| RevertedTagUpdateManager.php | ||
| RevisionSlotsUpdate.php | ||
| SqlBlobStore.php | ||