Skip to content

Conversation

@adrian-prantl
Copy link

The old behavior was to return a null string in the error case,when refactoring the error handling I thought it would be a good idea to print the error in the description, but that breaks clients that try to print a description first and then do something else in the error case. The API is not great but it's clear that in-band errors are also not a good idea.

rdar://133956263
(cherry picked from commit 7553fb1)

Conflicts:
lldb/test/API/commands/expression/diagnostics/TestExprDiagnostics.py

@adrian-prantl adrian-prantl requested a review from a team as a code owner November 21, 2024 23:42
@adrian-prantl
Copy link
Author

@swift-ci test

The old behavior was to return a null string in the error case,when
refactoring the error handling I thought it would be a good idea to
print the error in the description, but that breaks clients that try to
print a description first and then do something else in the error case.
The API is not great but it's clear that in-band errors are also not a
good idea.

rdar://133956263
(cherry picked from commit 7553fb1)

 Conflicts:
	lldb/test/API/commands/expression/diagnostics/TestExprDiagnostics.py
@adrian-prantl
Copy link
Author

@swift-ci test

@adrian-prantl adrian-prantl merged commit db02b99 into swiftlang:swift/release/6.1 Dec 2, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants