mediawiki-extensions-AbuseF.../includes/Consequences/ConsequenceNotPrecheckedException.php

<?php

namespace MediaWiki\Extension\AbuseFilter\Consequences;

use RuntimeException;

class ConsequenceNotPrecheckedException extends RuntimeException {
	public function __construct() {
		parent::__construct(
			'Consequences that can disable other consequences should ' .
				'use shouldDisableOtherConsequences() before execute()'
		);
	}
}
Represent Consequences with command objects The consequence-taking logic is moved away from AbuseFilterRunner, to dedicated classes. There's now one class per consequence, encapsulating everything it needs to take the consequence. Several interfaces allow customizing different types of consequences. Every "special check" in AbuseFilter was generalized to use these interfaces, rather than knowing how to handle each consequence. Adding more consequences from other extensions will also be easier, and it should happen via a hook (not a global), returning a class that implements Consequence. The BCConsequence class was temporarily added for legacy custom consequences. A ConsequenceFactory class is added to instantiate consequences; this would possibly benefit from using ObjectFactory, but it doesn't because it would also reduce readability (although we might do that in the future). These classes are still not covered by unit tests, and this is left to do for later. The new unit tests should mostly replace AbuseFilterConsequencesTest. @covers tag were added to keep the status quo (i.e. code that was considered covered while in AbuseFilterRunner will still be considered covered), although we'll have to adjust them. Change-Id: Ia1a9a8bbf55ddd875dfd5bbc55fcd612cff568ef 2020-10-11 21:17:41 +00:00			`<?php`

Create a dedicated namespace for all consequences-related classes Change-Id: Ibc39593e34da36e57b640af0b5bbf2145f725e92 2020-12-18 14:05:33 +00:00			`namespace MediaWiki\Extension\AbuseFilter\Consequences;`
Represent Consequences with command objects The consequence-taking logic is moved away from AbuseFilterRunner, to dedicated classes. There's now one class per consequence, encapsulating everything it needs to take the consequence. Several interfaces allow customizing different types of consequences. Every "special check" in AbuseFilter was generalized to use these interfaces, rather than knowing how to handle each consequence. Adding more consequences from other extensions will also be easier, and it should happen via a hook (not a global), returning a class that implements Consequence. The BCConsequence class was temporarily added for legacy custom consequences. A ConsequenceFactory class is added to instantiate consequences; this would possibly benefit from using ObjectFactory, but it doesn't because it would also reduce readability (although we might do that in the future). These classes are still not covered by unit tests, and this is left to do for later. The new unit tests should mostly replace AbuseFilterConsequencesTest. @covers tag were added to keep the status quo (i.e. code that was considered covered while in AbuseFilterRunner will still be considered covered), although we'll have to adjust them. Change-Id: Ia1a9a8bbf55ddd875dfd5bbc55fcd612cff568ef 2020-10-11 21:17:41 +00:00
			`use RuntimeException;`

			`class ConsequenceNotPrecheckedException extends RuntimeException {`
			`public function __construct() {`
			`parent::__construct(`
			`'Consequences that can disable other consequences should ' .`
			`'use shouldDisableOtherConsequences() before execute()'`
			`);`
			`}`
			`}`