It's an interesting concept. At least in part, I/we already use that in our team, in the sense that we e.g. only use the 'service' suffix for a very specific subset of usages, while other classically service-suffixed Spring beans are given more direct (and typically shorter) names.
For exceptions in particular, the value of the approach also depends on the granularity of the exception classes. When you have many classes with specific concerns, Kevlin Henney's can indeed be beneficial. When you have generic exception classes(*) that have internal state that reflects the differences in meaning, then there may be far less benefit (though in that case, class names also tend to be shorter already).
(*) whether that in itself is good/bad/not-OOP is a separate discussion
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It's an interesting concept. At least in part, I/we already use that in our team, in the sense that we e.g. only use the 'service' suffix for a very specific subset of usages, while other classically service-suffixed Spring beans are given more direct (and typically shorter) names.
For exceptions in particular, the value of the approach also depends on the granularity of the exception classes. When you have many classes with specific concerns, Kevlin Henney's can indeed be beneficial. When you have generic exception classes(*) that have internal state that reflects the differences in meaning, then there may be far less benefit (though in that case, class names also tend to be shorter already).
(*) whether that in itself is good/bad/not-OOP is a separate discussion