All of the internal protocol handlers are restricted to {.raises.} of [CancelledError]. However, the LPProtoHandler type is part of the public interface, and example / test code raises more errors than just [CancelledError]. The caller is aware of that and CatchableError is caught.
To allow annotating the internal handlers with the proper {.raises.} annotation, support for an extra LPProtoHandler2 is added. This is backward compatible as the old LPProtoHandler is still allowed. Examples still compile fine. There is one test that needs a slight adjustment as it accesses the internal handler field directly. That field needs to be renamed so that the template is used instead.
Eventually, LPProtoHandler may be phased out, with appropriate notices to users who define custom handlers and the migration requiring errors to be handled inside the handler instead of raising them. At this time, such a deprecation is not yet applied, especially while the internal logic is still relying on the previous handler flow.
All of the internal protocol handlers are restricted to
{.raises.}
of[CancelledError]
. However, theLPProtoHandler
type is part of the public interface, and example / test code raises more errors than just[CancelledError]
. The caller is aware of that andCatchableError
is caught.To allow annotating the internal handlers with the proper
{.raises
.} annotation, support for an extraLPProtoHandler2
is added. This is backward compatible as the oldLPProtoHandler
is still allowed. Examples still compile fine. There is one test that needs a slight adjustment as it accesses the internalhandler
field directly. That field needs to be renamed so that thetemplate
is used instead.Eventually,
LPProtoHandler
may be phased out, with appropriate notices to users who define custom handlers and the migration requiring errors to be handled inside the handler instead of raising them. At this time, such a deprecation is not yet applied, especially while the internal logic is still relying on the previous handler flow.