I'm thinking to implement a rule that it have sense to me in my experience but I'm not sure if it's ...

# detekt

[Brais Gabin]

I'm thinking to implement a rule that it have sense to me in my experience but I'm not sure if it's backed up by any book, good practices, general consensous... I would like a rule that forbids to extend a Throwable with a data class. Example data class Foo(val status: Int) : IllegalStateException(). The reason is that any Throwable stores information about were it was instantiated. For that reason the equals that data class implements is missleading. Two equal instances of Foo have different behaviour. My question: do you know any source talking about this? Does a rule like this have sense to you?

[Javier]

All exception classes extends throwable, isn’t there the same problem?

[ephemient]

in principle, one with enableSuppression=false and writableStackTrace=false would not have extra associated state, but you probably can't easily check that up the class hierarchy

[Brais Gabin]

The problem is not to extend from Throwable (that's fine) the problem is to use a data class that implementes the equals.

[ephemient]

yes, I'd be in favor of not allowing data class subclasses of any Throwable subtype by default

[eygraber]

I'm assuming this is in regards to https://github.com/detekt/detekt/issues/5521#issuecomment-1321249652?

In which case that was a contrived example 😅

[eygraber]

So yes, a rule for that would probably be welcome

[ephemient]

in principle

data class SafeException(override val message: String, override val cause: Throwable?) : RuntimeException(message, cause, false, false)

should be ok, but I think it's rare enough that it could be individually suppressed

[Brais Gabin]

Yes, related with that (I'm just answering you there :P). You give me the idea. But I saw that on production on different projects already.

[eygraber]

I have a clarification. I'll post that in the issue