> 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. 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
