Compilation error is not thrown from KSPLogger logging error in `1.6.10-1.0.3`
See original GitHub issueI have a SymbolProcessor
which was throwing a KotlinCompilation.ExitCode.Compilation.ExitCode.COMPILATION_ERROR
from environment.logger.error()
as expected in 1.0.2
. I have some unit tests to catch the error, which is now failing with 1.0.3
because it returns KotlinCompilation.ExitCode.Compilation.ExitCode.OK
, and the KSPLogger
API doesn’t fail the compilation.
Is this intended? If so, is there a more preferred way to fail the compilation?
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (1 by maintainers)
Top Results From Across the Web
compilation error while throwing exception? - java
The problem is because you are throwing a RuntimeException , but trying to catch SQLException . In your method,
Read more >Kotlin Flow compilation error - Support
TL;DR: I encourted a compilation error when using Kotlin Flow, that looks similar to the issue: Details: I have a mathod that returns...
Read more >Errors - Pode
Pode has inbuilt Error logging logic, that parses Exceptions and ErrorRecords, and will return a valid log item for whatever method of logging...
Read more >Can an API throw a compile-time error instead of a runtime one?
It's obviously going to crash at runtime but Kotlin gives no compile-time warning or error regarding it. Is there a way to throw...
Read more >compilation error when using compose compiler:1.2.0 ...
20 based on these commits; I can see the 1.2.0-alpha05 version in Stack trace, but I have not seen this on the project's...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Fixed in another way in #865.
Here is a patch to KCT to partially fix this problem: Unfortunately INTERNAL_ERROR is no longer possible; Any previous INTERNAL_ERROR in KSP becomes COMPILATION_ERROR until the fix lands in Kotlin compiler and KSP switches back.
I cannot think of any workaround in processors or outside of kotlin-compile-testing, because KSP always returns OK. It returns OK even when processor throws an exception.