feat: generate Exception subclass per API error type

[vdusek]

Summary

Addresses #423. Each ErrorType enum member from the OpenAPI spec now has a matching ApifyApiError subclass (e.g. RecordNotFoundError, ActorNotFoundError, InsufficientPermissionsError, ...) auto-generated into src/apify_client/_generated_errors.py by the existing model-postprocess step.

ApifyApiError.__new__ dispatches to the right subclass based on the response's error.type. Unknown types and unparsable bodies fall through to the base ApifyApiError. Direct subclass instantiation bypasses dispatch. except ApifyApiError handlers keep working because every generated class inherits from ApifyApiError.

Naming

• RECORD_NOT_FOUND → RecordNotFoundError
• BILLING_SYSTEM_ERROR → BillingSystemError (trailing _ERROR stripped)
• FIELD_3D_SECURE_AUTH_FAILED → Field3DSecureAuthFailedError (digit parts preserved)
• NOT_IMPLEMENTED → ApiNotImplementedError (Api prefix to avoid shadowing the builtin)
• SCHEMA_VALIDATION / SCHEMA_VALIDATION_ERROR → SchemaValidationError / SchemaValidationErrorError (collision fallback)

Usage

from apify_client.errors import ApifyApiError, RecordNotFoundError

try:
    client.dataset(id).get()
except RecordNotFoundError:
    ...
except ApifyApiError:  # still matches everything else
    ...

Migration note

Minor behavior change for 3.0 scope: constructing ApifyApiError(response, ...) directly now returns an instance of the matching subclass rather than always ApifyApiError itself. except ApifyApiError is unaffected; tests constructing the base class and asserting type(exc) is ApifyApiError would need updates.

[codecov]

Codecov Report

❌ Patch coverage is 99.75460% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 95.91%. Comparing base (3d4ce3f) to head (189e0aa).

Files with missing lines	Patch %	Lines
src/apify_client/errors.py	93.75%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #737      +/-   ##
==========================================
+ Coverage   95.26%   95.91%   +0.64%     
==========================================
  Files          45       46       +1     
  Lines        5115     5918     +803     
==========================================
+ Hits         4873     5676     +803     
  Misses        242      242              

Flag	Coverage Δ
integration	95.91% <99.75%> (+0.64%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[vdusek]

Let me guys know whether you think this is worth it. Currently, I'm slightly more inclined not to do it and keep the status quo. Since the API type errors are just general strings, they can often change.

[janbuchar]

Arguments in favor

1. Better DX - easier to catch individual types of exception, while you can still just catch ApifyApiError if you don't care much
2. Better DX - the exception name has a non-generic name, and that's the first thing you look at when you see an exception traceback in logs

Arguments against

1. It' a lot of generated code
2. We need to maintain the generator
3. If an error type disappears from a response object, it might get deleted from the code base, which is a breaking change (but it's also a breaking change in the API, so I'm not sure about the validity of this concern)