How do you decide between a checked and an unchecked exception, and how do you handle exceptions in a service?

Use a checked exception only when the caller can realistically recover and you want the compiler to force a decision; use unchecked for programming errors and for failures nobody up the stack can fix. In practice most modern Java code leans unchecked, wrapping low level failures in a domain exception that carries context, handled once at a boundary such as an exception handler that maps it to a response.

My test is whether a caller can do something useful about it. A payment declined by the provider is a legitimate business outcome, so that is either a checked exception or, more often, a result type. A null argument or a failed database connection is not something the calling code can fix, so it is unchecked. In services I mostly use unchecked domain exceptions, wrapping the underlying cause so the stack trace survives and adding the identifiers I will want in the log, like the order id, since a bare SQL exception three layers down tells me nothing. Handling happens once, at a boundary: in Spring that is an exception handler that maps each domain exception to a status code and a response body, so controllers stay clean. What I push back on in review is catching Exception broadly, catching and logging then continuing as if nothing happened, and empty catch blocks. I also use try with resources everywhere rather than finally blocks, because suppressed exceptions and close failures are handled correctly for free.