|
From: | Dustin Sallings |
Subject: | Re: [Gnu-arch-users] Nit |
Date: | Tue, 21 Oct 2003 12:00:30 -0700 |
On Tuesday, Oct 21, 2003, at 11:22 US/Pacific, Tom Lord wrote:
I'm not saying that exceptions should _never_ be let through, only that if you want a programming system to help you write robust code, then that system should require that you let through exceptions only explicitly, not implicitly.
But in the context of java-style checked exceptions, this is the case. If an exception is declared, it must be handled.
If you throw a NoSuchUserException (as you described in a previous example), it must do what it is defined to do. If you're raising an exception for a different reason that requires different handling, but calling it a NoSuchUserException, you're doing something stupid. If you have a different failure mode that must be handled differently, you declare a different type of exception, and everyone's happy.
I think this is pretty much what you're describing, except you are adding a scenario where you want to have a different failure mode, but not indicate it as a different failure mode by calling it a different exception. In the real world, you'd just call it a different exception and move on.
Now, you might have different reasons for a NoSuchUserException that you want to be able to handle differently sometimes, but other times you don't care. In these cases, you could subclass, or include another code.
For example, I might have a NoSuchUserException with a subclass of UserHasExpiredException or something. For most uses of the API, if I ask for a user, I can just deal with NoSuchUserException and I don't particularly care why the user doesn't exist. In some cases, I might want to handle the case where a user has expired specifically. Caring about the distinction is not the rule, though.
-- Dustin Sallings
[Prev in Thread] | Current Thread | [Next in Thread] |