Should I avoid enabling coroutine stack trace recovery in production? The <docs> mention that the on...

# coroutines

[kevin.cianfarini]

Should I avoid enabling coroutine stack trace recovery in production? The docs mention that the only downside is referential transparency, but are there also performance considerations?

[kevin.cianfarini]

I also see that R8 rules will disable this, so surely there’s a performance penalty

[CLOVIS]

The performance impacts are minimal, I'm not sure they can even be measured. It really is just a try … catch with a call to e.duplicate (or whatever that function is called). For some exceptions, a reflection call may be necessary. But, if your app is already using reflection-heavy libraries, like Spring or Jackson, I doubt you can measure a difference.

The reason it's not enabled by default is that some libraries use the referential identity of exceptions, and so enabling stack trace recovery breaks them 😕