Skip to content

Conversation

@augusto2112
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

(cherry picked from commit 091aa23)

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

(cherry picked from commit 091aa23)
@augusto2112 augusto2112 merged commit 54fd2f1 into swiftlang:stable/21.x Aug 18, 2025
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