On Thu, Apr 14, 2011 at 1:38 PM, Alexandre Bergel <[email protected]>wrote:
> > I think you said it right here: "having classes for all _relevant_ > concepts actually pays off"... > > I do not quite agree on this. Responsibility should be the driver, not the > concepts. > that is a good point > > Alexandre > > > > Related to exceptions, my question is: what are all the different > concepts you have? for example, not finding a Key or not finding a Value are > really different concepts? or is it the same (not finding something) that > depending on the context (finding a value or a key) is what looks like they > are different? if so, then there is only one concept (i.e. not finding an > object), if it is a key or a value is accidental, contextual to what you are > looking for. > > So, I completely agree when you say "having classes for all relevant > concepts"... I think we do not agree on what are the relevant concepts when > we talk about exceptions... > > > > > > Toon > > > > > > On 04/14/2011 01:00 AM, Dale Henrichs wrote: > > On 04/13/2011 02:58 PM, Toon Verwaest wrote: > > Is it such a problem if you duplicate a certain exception class? At the > > moment you'll do the same anyway by not completely writing the exact > > same symbol. > > > > It's a simple matter of namespaces and volume of names ... with a large > open ended namespace you are more likely to have a number of redundant names > with slight differences in spelling showing up in different spots in the > hierarchy...with a logically segmented namespace each segment will have a > manageable number of names and the risk of duplication is reduced ... end of > discussion ... > > > > 10,000 names vs 30 names ... I can easily recognize duplicates in a list > of 30 names ... not so easy in 10,000 ... that is all ... > > > > to attempt to map every possible error condition onto a class will lead > you to 10,000 much quicker than using reasonCodes ... that is all ... > > > > I don't hate classes, it is a _practical_ matter ... if _you_ would > rather manage 10,000 names then I will say that it isn't practical ... I'm > _not_ saying it is _wrong_, just not _practical_. > > > > > > And if the problem is not finding classes anymore, maybe we need a > > better way of organizing the exception classes away from the standard > > classes so that they are as non-intrusive as symbols, but convey more > > information? > > > > And now you've hit the nail on the head ... in order to handle the extra > complexity you need additional tools ... before creating more tools, ask > your self the simple question: "Do I _need_ the additional complexity?" ... > if the answer is yes, then create the tool, if the answer is no, then you > don't need to create a new tool .. > > > > Again, this is a _practical_ matter... > > > > > > self error: #keyNotFound > > does not really give much information; and isn't much more difficult to > > write than: > > KeyNotFoundException new in: self; key: key; signal > > > > From a practical perspective how many exception handlers will be written > to handle KeyNotFoundException ... I use at:ifAbsent: when I'm doing a look > up that I think might fail ... better than writing an exception handler ... > > > > If there is a real need to write a handler for KeyNotFoundException, then > by all means create the class, but until you actually NEED > KeyNotFoundException, `self error: #keyNotFound` or `NotFoundException > signal: #keyNotFound` will work just fine... > > > > although the second one gives you all the contextual information that > > the first one misses. > > > > _If_ you NEED the additional contextual information. It's just like > writing a framework that no uses ... there's nothing wrong with the idea or > the implementation, it's just that the framework didn't solve a problem that > anyone had... > > > > If you are going to create a class, I think the least it should do is > address an real problem, not an imaginary one. > > > > To say that "if one were to handle the KeyNotFoundException, they will > need the complete context", I prefer to say "Until one needs the complete > context of the KeyNotFoundException, don't bother creating class" > > > > > > What I mean mostly: what about trying to figure out why you want to > > avoid decent exception classes and tackling that problem? > > > > Depends upon what your definition of a decent exception classes is? My > argument is simply that it is not _necessary_ to create a unique class for > every unique error condition ... I think that folks should answer the > question: "Will anyone every write an exception handler for this exception" > before creating the class ... if the answer is yes (or better yet, I am > writing code right now and need that exception) then by all means create the > class. > > > > Maybe we don't want classes but exception objects that can pool data > > together? Maybe a very silly idea: what about just exception "classes" > > that have dictionaries to store enough information? > > > > That would be another way of doing things ... although using exception > classes and reasonCodes is pretty close to all that is needed... > > > > I agree with the notion that it isn't that useful to have a single Error > class and have all errors mapped to it ... on the other hand I don't think > it is particularly useful to have an exception class for every possible > error condition ... the compromise is to provide a smallish hierarchy of > excpetion classes with fairly general structure, provide a means for > uniquely identifying every possible error condition (I think that is > important) and then add new classes to the hierarchy when a demand for the > class is found ... > > > > > > > > > > > > > > > > -- > > Hernán Wilkinson > > Agile Software Development, Teaching & Coaching > > Mobile: +54 - 911 - 4470 - 7207 > > email: [email protected] > > site: http://www.10Pines.com > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: [email protected] site: http://www.10Pines.com <http://www.10pines.com/>*
