The same unavailable capability produced two exception types.
BaseEventLoop.sendfile() can use an operating system’s native sendfile support or fall back to a manual transfer. When a caller passes fallback=False, native unavailability is part of the public result: asyncio exposes SendfileNotAvailableError for that condition.
Before PR #152223, transports marked TRY_NATIVE followed that contract, but fallback-only transports such as SSL/TLS raised a generic RuntimeError. Both paths represented the same practical result—native sendfile could not be used and fallback had been disabled.
A fallback branch bypassed the public exception type.
After asyncio determined that a transport required the fallback implementation, the not fallback branch raised RuntimeError directly. That made exception handling depend on the transport’s internal sendfile mode rather than on the caller-visible condition.
SendfileNotAvailableErrorRuntimeErrorThe expected contract was a single specific exception for native sendfile unavailability. Because SendfileNotAvailableError subclasses RuntimeError, adopting the specific type preserves compatibility for callers already catching the base class.
Change the narrow fallback-disabled branch.
The merged patch replaces the generic exception in that branch with asyncio.SendfileNotAvailableError. Unsupported transports and closing transports continue to use their existing RuntimeError behavior; the contribution does not broaden or restructure sendfile handling.
if not fallback:
raise SendfileNotAvailableError(
"fallback is disabled and native sendfile is not supported"
)Protect the public exception contract.
The existing fallback-transport test was updated to expect SendfileNotAvailableError while retaining the message assertion. The PR record documents focused execution of the individual regression and the asyncio sendfile test module. The accompanying library news entry records the behavioral correction for fallback-only transports such as SSL/TLS.
Specific exceptions make capability failures actionable.
- Public exception types should describe the caller-visible condition rather than an internal branch.
- A more specific subclass can improve diagnostics while retaining compatibility for broad exception handlers.
- Narrow fixes are preferable when adjacent error cases intentionally have different meanings.