axios error.response is undefined on network-level failure

Goal

Centralize axios error inspection in a response interceptor so status-dependent logic runs only when an HTTP response exists, while network-level failures surface without a secondary TypeError.

Constraint

Axios leaves error.response undefined for DNS failures, connection refused, and other network-level errors. Reading error.response.status directly throws before fallback logic can run. Recent axios versions favor AbortController over the deprecated CancelToken, and mixing both cancellation styles is unpredictable.

Uncertainty

It is unsettled whether an interceptor should check error.response first, use error.code and error.request as discriminators, or treat AbortController cancellation as a separate failure class during an upgrade.

Should error.response.status be accessed with optional chaining or an explicit undefined check?

Are error.code and error.request reliable for distinguishing network failures across Node.js and browsers?

How should cancellation errors from AbortController be separated from network errors without using CancelToken?