Bruno Desthuilliers @ Thursday 21 August 2008 22:54: > magloca a écrit : >> Bruno Desthuilliers @ Thursday 21 August 2008 17:31: >> >>>>> If you mean "the exceptions *explicitely raised* by your code", >>>>> then I agree. But with any generic enough code, documenting any >>>>> possible exception that could be raised by lower layers, objects >>>>> passed in as arguments etc is just plain impossible. Like, if you >>>>> have a function that takes a file-like object as arg, you just >>>>> cannot know in advance what exceptions this object might raise. >>>>> >>>> This is one of the main concerns with which I started this c.l.py >>>> thread ! I think it's a pity that we have no way of anticipating >>>> and constraining the exceptions thrown by our code, >>> Java's "checked exception" system has proven to be a total disaster. >> >> Could you elaborate on that? I'm not disagreeing with you (or >> agreeing, for that matter); I'd just really like to know what you >> mean by a "total disaster." > > One of the most (in)famous Java coding pattern is the empty catchall > clause. Read Chris Mellon and Richard Levasseur posts in this thread > for more details - they already covered the whole point.
Thanks, I missed those. Having read them, I *am* agreeing with you. Personally, I also dislike the predominance in the Java world of only giving type information -- IllegalValueException, ObjectRetrievalFailureException, and whatever. What was the illegal value? What object couldn't be retrieved? How hard is it to use the with-error-message version of the Exception constructor, and include something that might actually be helpful in debugging? m. -- http://mail.python.org/mailman/listinfo/python-list