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.