Why Framework "Magic" Can Be More Dangerous Than Plain Java

Frameworks are great at reducing boilerplate, until they start hiding important details.

`@SneakyThrows` is a good example. It removes the need to declare or catch checked exceptions, making the code look cleaner at first glance. But that "magic" comes at a cost: the method's exception contract becomes invisible.

When exceptions aren't explicit:

In plain Java, checked exceptions force you to make decisions. You either handle the failure or consciously propagate it. That friction is not a flaw, it's a design signal.

Using `@SneakyThrows` may feel like a shortcut, but shortcuts tend to accumulate invisible debt. Readability, explicit contracts, and predictable behavior usually age much better than convenience.

My Approach

Personally, I avoid `@SneakyThrows`. I prefer explicit exception handling, wrapping exceptions when needed, or designing clearer exception contracts. These approaches make failures visible, code easier to reason about, and systems safer to evolve over time.

Frameworks should help us write better code not hide the complexity we still need to understand.

What do you think?

Have you ever had problems caused by `@SneakyThrows`? Do you like using it, or do you prefer more explicit approaches? Let me know what do you think about sneaky throws and also your experiences with other framework features that look like magic, but end up doing more harm than good in the long run.