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
This patch touches all uncontroversial (I hope) places where a chain
of isset(), array_key_exist() and the ternary ?: operator can be
replaced with the much shorter ?? feature from PHP 7.
?? does the same. It checks if the element before the ?? is set and
not null. When this check fails, the element after the ?? is used.
Change-Id: Id612e2782ae928164b26b6f0de676c6c7d8302f3
For those that still need the precision of time, the
DateTimeInputWidget can be used.
Bug: T107069
Change-Id: I2e0b0168b53594760c2630dc4ecd4e6af7404a7c
No longer needed after I08244addcf9b6eb96137895f28e7b750914fef5c.
Also remove datetime.js from mediawiki.htmlform module.
Change-Id: Ic2410c689de3f70f573fa1c71456e6d3f334f80b
It mostly already worked. HTMLForm::trySubmit() needed a little
adjustment to handle things properly.
Change-Id: Ibb17bb61ac0b2d41953249980bc2f23b8a3ae5b6
