Got it, you make a good point. Yeah I imagine the unknown-user case is more common that I had supposed. OK, disregard the comment about DataModel knowing about all users. It's not always going to be the case nor I suppose is it necessarily desirable.
So let's see, the code does handle this situation. I suppose the remaining question is whether the method should return null or throw an exception? I still imagine the overhead of exceptions is virtually nil and I mildly prefer exceptions to null. So yeah it boils down to throwing a different exception? Sure, how about I invent a NoSuchUserException as a subclass of TasteException? Can-do. Sean On Wed, Jan 21, 2009 at 10:06 PM, Otis Gospodnetic <otis_gospodne...@yahoo.com> wrote: > Hello, > > > ----- Original Message ---- >> From: Sean Owen <sro...@gmail.com> >> >> Yeah let's see, to boil it down: either way there has to be a way to >> signal the user isn't known, and either way the caller has to handle >> it. I've always preferred exceptions to null, all else being equal. I >> don't mind the idea of exceptions being used for control flow; they >> aren't that expensive. (In a performance-critical block, OK, I'd use >> null instead, but here, this case is rare enough that I don't think >> performance is a factor.) > > I think this last bit is an assumption. I'm working with a setup where 80% > of recommendation requests will be for unknown users. > Imagine a web site that is not super sticky. New users pass through all the > time. Most users are irregular visitors. The system gets their ID from a > cookie, but doesn't know much else about that user. > >> Catching an exception needs a bit more code than handling null. You >> can't force a caller to handle null, but you can force a caller to >> handle an exception -- but here I'm using an unchecked exception so >> that doesn't matter anyway. You have a point about catching this maybe >> masking another exception. >> >> I could be talked into changing this, but here, I think the right >> behavior for a DataModel is to know about all users that exist, not >> just ones with preferences. That is this user should be known in your >> situation. > > I think there'll always be unknown users in my case. The reason I have such > a high % of unknown users is because in addition to what I described above, I > furthermore skip "noisy users" and don't have the FileDataModel read them. I > skip users who don't have much history - users for whom I don't have enough > data to make good recommendations. If I keep them, they consume my precious > JVM heap and recommendation computation is slower. If I skip them, I see > noticeable improvement in performance (and I haven't noticed degradation in > quality so far... should I have?) > >> But are you using FileDataModel or something similar? because this >> condition isn't really fulfilled by this implementation. It only knows >> about users that have expressed a preference, by its nature. That can >> be addressed so that you can express users, without expressing a >> preference. > > I think the above explains my particular situation. > >> If this is the issue -- let me attack that issue directly to solve >> this, and punt on the exception vs. null discussion. Am I right? > > I'm doing okay performance-wise after I skip my noisy users, so this is not a > huge problem for me. Perhaps just changing the exception to a specific > checked exception would be an improvement if handling null is too much of a > pain. > > Otis
