<https://blog.shreyaspatil.dev/kotlin-exception-handling-why-singleton-exceptions-are-a-bad-idea>

# feed

[Shreyas Patil]

https://blog.shreyaspatil.dev/kotlin-exception-handling-why-singleton-exceptions-are-a-bad-idea

[ephemient]

exceptions can be created without a stack trace, which would also prevent them from being misleading

[Stefan Oltmann]

I once ran into this, too. 😄

What use do Exceptions without a stack trace have?

[Stefan Oltmann]

I feel Detekt should have a rule for singleton/`object` Exceptions.

[ephemient]

control flow exceptions that aren't exposed to the user

[Stefan Oltmann]

Ok, I see. Control flow exceptions are considered being an anti-pattern in my world. 😉

[Stefan Oltmann]

( No, I don't have an alternative for CancellationException 😅 )

[Pavel Haluza]

@Stefan Oltmann Detekt has the rule 🤓

https://detekt.dev/docs/rules/exceptions/#objectextendsthrowable

[CLOVIS]

Control flow exceptions are considered being an anti-pattern in my world.

Actually it's the opposite way around 😅 Control flow exceptions are bad because their stacktrace is expensive

If you disable stacktraces, and carefully write a DSL so the exception cannot "leak", you can use them fairly safely as a sort of more powerful non-local return

The best example I know is https://arrow-kt.io/learn/typed-errors/working-with-typed-errors/