Re: [Gnu-arch-users] Nit

[Dustin Sallings]

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