On Thu, Apr 14, 2011 at 5:33 AM, Toon Verwaest <[email protected]>wrote:
> Somehow I feel like I offended someone :) > > I personally don't have experience with 10'000+ classes in a system. I do > understand that's where you are coming from and do appreciate the insight. > > My personal experience has rather been the opposite until now. For example > the Pharo/Squeak classbuilder is 1 single class doing everything. This is > horrible; not just horrible because the code is completely horrid but it's > non-extensible, non-configurable, non-reusable, contains tons of duplication > _just because_ it is all put into one big ball of mud. By decomposing the > classbuilder into 4 to 10 different classes I ended up having very little > methods with very little code, and a very high level of configurability and > understandability. I now actually use this classbuilder to build anonymous > classes too, avoiding the whole problem with forgetting to copy in the > format that everyone seems to have. > > And this experience was showing me that having classes for all _relevant_ > concepts actually pays off in the long run. Since you (and others) are > saying that it doesn't for exceptions; and since I don't have enough > experience there I'll take your advice into account when writing code ;) > I think you said it right here: "having classes for all _relevant_ concepts actually pays off"... 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 <http://www.10pines.com/>*
