[TDannhauer]

Summary

• Adds the marker interface Horde\Exception\InvalidDataThrowable (extends HordeThrowable), following the PermissionDeniedThrowable pattern.

Motivation

Applications throw their own exception classes when a caller supplies data they cannot store (a Turba attribute over its configured maxlength, for example). Protocol handlers in other packages — Horde_Core_ActiveSync_Driver in this case — need to distinguish "the client's data is invalid, do not retry" from "the server failed, try again" without depending on Turba_* classes. A framework-level marker interface keeps that check implementation-agnostic.

Context: horde/turba#73 (attribute constraints only enforced in the web form; ActiveSync clients resend a rejected contact forever because it is reported as a server error).

Changes

• src/InvalidDataThrowable.php — empty marker interface with docblock describing the contract (the exception message describes the invalid input; retrying with the same input will fail again).

Related PRs

• fix(turba): enforce attribute constraints on every write path turba#74 — Turba_Exception_InvalidAttribute implements InvalidDataThrowable
• fix(core): report rejected client data as ActiveSync Status 6 Core#248 — maps InvalidDataThrowable to ActiveSync STATUS_INVALID
• feat(activesync): let backends set the per-item status of a failed change ActiveSync#111 — importer honours the backend-supplied status

Note for release: adding the interface is a minor-version feature; the dependent packages currently require horde/exception: ^3 || dev-FRAMEWORK_6_0 and will need ^3.1 (or whichever version ships this) once released.

Test plan

• php -l src/InvalidDataThrowable.php
• Consumers tested in the Turba and Core PRs (Turba_Exception_InvalidAttribute instanceof InvalidDataThrowable)

[ralflang]

I am not against it but I wonder if we are not better off basing this on either InvalidArgumentException or UnexpectedValueException (a runtime exception which says "this value doesn't fit the constraints"

[TDannhauer]

Agreed that UnexpectedValueException is the natural SPL fit — your docblock on HordeUnexpectedValueException describes exactly this case ("typically from external sources like … user input … a data validation failure").

The reason for a marker interface instead of a base class is Turba_Exception: it extends Horde_Exception_Wrapped, and 42 catch (Turba_Exception $e) sites in turba/core (API, CardDAV, import, ActiveSync driver) must keep catching the new Turba_Exception_InvalidAttribute. With single inheritance it cannot also extend UnexpectedValueException. The same holds for every other legacy <App>_Exception. The interface lets an app add the "client data, do not retry" classification on top of its existing hierarchy — same pattern as PermissionDeniedThrowable.

The two are not exclusive: once the Turba exceptions move to src/, extends HordeUnexpectedValueException implements InvalidDataThrowable would give us both the SPL semantics and the retry-policy marker.