[Pharo-project] Improving Pharo's Exception Hierarchy

Hernan Wilkinson hernan.wilkinson at 10pines.com
Thu Apr 14 18:56:41 CEST 2011


On Thu, Apr 14, 2011 at 1:38 PM, Alexandre Bergel
<alexandre.bergel at me.com>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: hernan.wilkinson at 10Pines.com
> > 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: hernan.wilkinson at 10Pines.com
site: http://www.10Pines.com <http://www.10pines.com/>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110414/54c01eb8/attachment.htm>


More information about the Pharo-project mailing list