I could pass a `Class<T>` into the exception...

# announcements

[diesieben07]

I could pass a Class<T> into the exception.

[Ruckus]

How would that help you? You can already pass a Class<*>.

[diesieben07]

I can pass a Class<*>, yes. However that does not give me type safety.

[diesieben07]

If I pass a Class<T> and a T I know they are of the same type.

[diesieben07]

Class<*> and Any does not give me that.

[Ruckus]

Indeed, but why do you need a Class<T> in the exception? What's wrong with just throwing the offending instance in it and getting the class off it?

[diesieben07]

In my case I had a DiKey<T> and a T instance. I wanted to write an exception class which had those two instances as properties.

[diesieben07]

Maybe a rare edge case, but it seems like an unneeded limitation.

[Ruckus]

I don't think it's so much an edge case as it is a misuse of the exception handler. If you're flow is so well structured and handled, it could be a sign you're abusing the exception flow, but that's a difficult (and frankly rather opinion based) issue.

[diesieben07]

I think "cycle in dependency graph" is a pretty valid use case for throwing an exception...

[Ruckus]

Depends on the work flow. Many people have different ideas on what is valid for throwing and exception. I tend to lean towards exceptions are for irrecoverable/crashing states, but like I said, it's very opinion based.

[diesieben07]

Yes, in this case that is an irrecoverable state 🙂

[Ruckus]

Right, but it's also expected, at least well enough that you know exactly what the problem is, where it happened, and even have some meta data associated with it, so it sounds to me like you should use a return value with that data, not an exception.