This reverts commit 0d453d915a.
Reason for revert: Trying to find a better approach than an abstract class
Change-Id: I69c0ec25cb920f41cb0eb6b3ad921d7b02290581
AbstractLocalizedException acts like a shim to ILocalizedException in preperation for refactoring
Bug: T287405
Change-Id: I01e40e82457d49487829d9a435b7a1198369ecf6
For compliance with the new version of the table interface policy
(T255803).
This patch was created by an automated search & replace operation
on the includes/ directory.
Bug: T257789
Change-Id: Ie32c1b11b3d16ddfc0c83a757327d449ff80b2e4
For compliance with the new version of the table interface policy
(T255803).
This patch was created by an automated search & replace operation
on the includes/ directory.
Bug: T257789
Change-Id: I5ffbb91882ecce2019ab644839eab5e8fb8a1c5f
For compliance with the new version of the table interface policy
(T255803).
This patch was created by an automated search & replace operation
on the includes/ directory.
Bug: T257789
Change-Id: If560596f5e1e0a3da91afc36e656e7c27f040968
This annotates classes that can safely be instantiated by
extensions, per the Stable Interface Policy.
Bug: T247862
Change-Id: Ia280f559874fc0750265ddeb7f831e65fd7d7d6a
The same way it does already for non-error output. This makes
it so that doPreOutputCommit() consistently happens between
the staging of output and the actual sending of output.
It is still allowed for code to bypass this, such as for fatal
errors and for handlers that disable OutputPage (like Special:Export).
But for cases where we do want to perform doPreOutputCommit(), it
should be run consistently between staging and sending so that it
can make appropiate decisions based on the current state of
OutputPage.
Previously, the state of OutputPage seen by doPreOutputCommit()
would be the broken/incomplete output of a seemingly succesful
(possibly cacheable) user action, which would then, after
doPreOutputCommit() runs, be completely replaced by $e->report()/
$out->showErrorPage().
This is a prerequisite for being able to reliably send cookie-block
cookies on error pages (next patch).
Bug: T233594
Change-Id: Iaeaf5e55a5868e6be534ddda73f3b56b9d6ef8f0
Right now, ErrorPageError *assumes* you're never running on the cli
or the API. It's kinda a crappy superclass to use for errors unless
you're 1000% sure you'll never hit that code path. Yay assumptions!
Ideally, all of this report() crap is cleaned up and unified across
the like 1192902117 places we have it spread out, but for now just
detect the scenario and delegate back to MWException, which does the
right thing
Bug: T168337
Change-Id: Ia2f490528e128527a7a5ef1f4f5eea36ec9ee810
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I6f59febaf8fc96e80f8cfc11f4356283f461142a
We already throw around some exceptions that are localized
(ErrorPageError and its subclasses, MalformedTitleException), but
there's no standard way to recognize them. Let's change that.
Then let's use them in the API to be able to have internationalized
errors when such exceptions are caught, instead of wrapping the
English-language version.
Change-Id: Iac7c90f92a889f8de9dae373547c07b884addaea
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I41a84e8e1dec39170aa655250325ffc485eaeaef
