Hi!
Recently it seems as though there's been a huge increase in the use of
exceptions within the MediaWiki ecosystem. That's perfectly fine.
Exceptions are fantastic and a standard part of any developer's toolkit.
However, there seems to be a trend in throwing exceptions for codepaths
that don't catch them prior to returning to the user. The one I'm calling
out in particular is InvalidArgumentException.
It seems as though some code paths that are relying on user-generated input
are throwing this exception. That's pretty evil. There's a couple of
reasons:
- This just returns a generic 503 error to our users. They don't know what
went wrong and they're left wondering why and filing bugs.
- Due to our current logging setup, we don't do nice parameter grouping for
exceptions. This means that each one is reported on its own, and we don't
have an idea of the scale/severity of the problem. We need to fix this, but
it doesn't preclude us being more proactive.
Basically the short version is: exceptions should only be shown to users in
the situation of *actual software errors*. They're the exception, not the
norm. What we *should* do in such situation is log the error (at the
ERROR/WARNING/etc level as appropriate) and then gracefully fall back.
I don't think we need an RfC or anything formal here, just a little bit of
common sense :)
Tldr: if there's no such user "Foo", we shouldn't return an exception when
a user tries to perform an action on it. We should return a helpful error
message, log it, and fall back gracefully.
-Chad
PS: Now that I think about it, there's been a proliferation of
RuntimeException for the exact same thing.
