Skip to content

Separate error description vs localizedDescription #730

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
weissi opened this issue Feb 7, 2025 · 1 comment · Fixed by apple/swift-openapi-runtime#143
Closed

Separate error description vs localizedDescription #730

weissi opened this issue Feb 7, 2025 · 1 comment · Fixed by apple/swift-openapi-runtime#143
Assignees
Labels
area/runtime Affects: the runtime library. good first issue Good for newcomers kind/bug Feature doesn't work as expected.

Comments

@weissi
Copy link
Member

weissi commented Feb 7, 2025

Description

In pure Swift programs it's quite important to not call .localizedDescription on random error types -- unless they are verified to be proper NSErrors. Unfortunately, ClientError's description does just that.

Consider this Swift program

import Foundation

public enum SomeSwiftError: Error {
    case aFailed
    case bFailed
}

do {
    throw SomeSwiftError.bFailed
} catch {
    print("correct (just print)", error)
    print("incorrect (localizedDescription)", error.localizedDescription)
}

the output is

$ swiftc bad.swift && ./bad
correct (just print) bFailed
incorrect (localizedDescription) The operation couldn’t be completed. (bad.SomeSwiftError error 1.)

See how localizedDescription just prints The operation couldn’t be completed. (TYPE error 1.). Even the error number is statically just 1.


Bottom line: If I do print(errorFromOpenAPIRuntime) I always get The operation couldn’t be completed. (AsyncHTTPClientError error 1.) with no further information.


Underlying bug is swiftlang/swift#58724

Reproduction

n/a

Package version(s)

latest

Expected behavior

prints the correct error, crucially it must never call localizedDescription.

Environment

all

Additional information

No response

@weissi weissi added kind/bug Feature doesn't work as expected. status/triage Collecting information required to triage the issue. labels Feb 7, 2025
@czechboy0
Copy link
Contributor

Hi @weissi,

you're right that we're not correctly forwarding the localizedDescription vs description calls.

We should make sure that any wrapper errors, in their localizedDescription call the underlying error's localizedDescription, and same for description.

Using this issue to track fixing that in ClientError and ServerError at least, and audit we don't need it anywhere else.

@czechboy0 czechboy0 changed the title Runtime calls .localizedDescription on errors it gets from the transport --> loses all error information Separate error description vs localizedDescription Feb 8, 2025
@czechboy0 czechboy0 added area/runtime Affects: the runtime library. good first issue Good for newcomers and removed status/triage Collecting information required to triage the issue. labels Feb 8, 2025
@czechboy0 czechboy0 self-assigned this Feb 24, 2025
simonjbeaumont pushed a commit to apple/swift-openapi-runtime that referenced this issue Feb 24, 2025
### Motivation

Fixes apple/swift-openapi-generator#730.

We were not correctly keeping `CustomStringConvertible` and
`LocalizedError` conformances separate for wrapper errors like
`ClientError` and `ServerError`. This lead to some user-thrown errors
(in handlers, transports, and middlewares) to print less information
than the error was actually providing (using a different method).

### Modifications

Properly untangle the two printing codepaths, and only call
`localizedDescription` from the wrapper error's `errorDescription`.

Also made the `localizedDescription` strings a bit more user-friendly
and less detailed, as in some apps these errors might get directly
rendered by a UI component that calls `localizedDescription`.

### Result

Error logging should now match adopter expectations.

### Test Plan

Added unit tests for `{Client,Server}Error` printing methods.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/runtime Affects: the runtime library. good first issue Good for newcomers kind/bug Feature doesn't work as expected.
Projects
None yet
2 participants