Maybe I am misunderstanding your point here, but isn't making RuntimeException be the base for internal problems the issue the parent poster was talking about? Divide by zero is an obvious case, but what about when invalid or misconfigured data of some type is passed into a method? This is "internal", ie inside the program, unless I am misunderstanding your terminology? It isn't an external problem, so it isn't a checked exception, which means that the caller to your method doesn't necessarily actually need to handle RuntimeException that you would throw, meaning we're back in the C world of optional error handling?
I might be missing your point, but I would think that making it so that only program-external problems throw checked exceptions defeats a lot of the forced error handling power that checked exceptions grant?
You can always make input validation errors a checked exception with your own exception type. It'll accomplish what you're trying to accomplish. It's not perfectly clean because it'd be nice if you could stick it under the "IllegalArgumentException" part of the inheritance tree, but it does what you're asking for.
Right but if you derive it from Error it isn't checked and same as if it is derived from RuntimeException. Deriving from Exception is checked but then you aren't fitting in with the hierarchy that pron is recommending, or at least what I think they are recommending, which is why I asked for clarification.
Internal errors are bugs or other conditions that the application is not expected to handle (other than, say, restart the thread a-la Erlang). Input validation is not an internal error. IllegalArgumentException is meant to represent bugs, and so an internal error, and so it is unchecked. It does not represent input validation errors.
I might be missing your point, but I would think that making it so that only program-external problems throw checked exceptions defeats a lot of the forced error handling power that checked exceptions grant?