Hi, here is my planned change to how KSP should ha...

# ksp

[Jiaxiang]

Hi, here is my planned change to how KSP should handle exceptions https://github.com/google/ksp/pull/321 (you can ignore the code change and only look at the document change on SymbolProcessor. I’d like to open up for discussion and hear back from you on how you think about this exception handling on how it can impact your developing experience (in good way or bad way). Mainly I would like feedbacks on whether other processors should continue processing when one processor throws an exception.

[Zac Sweers]

I am strongly in favor of failing early and fast

[Zac Sweers]

allowing other processors to proceed, particularly if they depend on outputs of the previous, can result in a huge amount of noise

[Jiaxiang]

the purpose of allowing other processor to proceed is to ensure the ordering is not a noise (e.g. bad code caused corruption in KSP/compiler). As for the output being a noise, since we fail after the round, so the output from other processors in the round of exception is not included therefore won’t impact.

[Zac Sweers]

I'm not sure I understand the "ordering is not a noise" reason

[Jiaxiang]

say if there are multiple processors in a project, the processor throwing exception might be the first processor in execution of a round, but may be second in other projects.

[Jiaxiang]

since in current plan, upon exception, all onError() s will be invoked, want to make sure the effect of onError() is consistent.

[Jiaxiang]

E.g. I have a processor with onError() overridden to dump debugging logs, and I am interested in when the error happens, so I am counting rounds inside my processor and therefore if we fail early I might be seeing inconsistent round number for same processor combination. I am not sure if that sounds a practical use case for processors though.