Handle non-MW specific exceptions better and refactor code to not needed them. Lots of code depends on MWException right now.
Some exception base class might be needed for structuring bits of data possibly...but should not be MW specific.
Handle non-MW specific exceptions better and refactor code to not needed them. Lots of code depends on MWException right now.
Some exception base class might be needed for structuring bits of data possibly...but should not be MW specific.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Invalid | None | T88360 Figure what to do with MWException within Wikibase | |||
| Declined | aaron | T76652 Make MWException handle non-MW exceptions better |
@aaron Can you be more specific?
In 2013 I refactored MWException; most logic was moved into static handlers and it no longer special-cases MWException. Handled for e.g. generating IDs and formatting debug log entries is now generic. See 4468a46af2 and f0386d3183.
We still reference the MW class in many places, but other than subclasses for concepts currently MW-specific (like Database, and OutputPage), it should be safe to start phasing it out in favour of plain exceptions. If not, let's find out what's left!
https://gerrit.wikimedia.org/r/#/q/topic:kill-mwexception,n,z
Marking stalled; per Krinkle's comment.
I wrote some complaints about the process in https://gerrit.wikimedia.org/r/184048. Having as much as possible of the process in public is important, as are small things like including reference to this task in the commit message.
The handler is OK (I've been doing some unrelated cleanups though). MWException could maybe have some stuff moved out of it, but that's less urgent.