Checked or UnChecked Excpetions - a compromise?

The general thought process in the above question is around the ability of the calling code to handle the reason for the exception (Update: Maybe not so general after all, see: internal-and-external-exceptions).
If we can, the exception should be checked, otherwise not.
This leaves still the bubbling issue. Let's say I catch a StaleObject exception in my data access code. I can deal with this - I tell the user someone updated the item and ask him to amend the latest version instead.
However, likelihood is that there are a lot of function calls and hence catch blocks between the code offering the solution to the user and the data access code discovering the problem.
I therefore introduced the ExpectedRuntimeException into my application. This allows me to ignore these kind of Exceptions up to the Service level. Here I can now easily deal with these in a different way to any other RunTimeException