[Pharo-project] Improving Pharo's Exception Hierarchy

Hernan Wilkinson hernan.wilkinson at 10pines.com
Thu Apr 14 15:46:21 CEST 2011

On Thu, Apr 14, 2011 at 10:37 AM, Camillo Bruni <camillo.bruni at inria.fr>wrote:

> On 2011-04-14, at 14:19, Hernan Wilkinson wrote:
> >
> >
> > On Thu, Apr 14, 2011 at 9:08 AM, Toon Verwaest <toon.verwaest at gmail.com>
> wrote:
> > Right, so you confirm the experience of Dale.
> >
> > In the case of flagging errors without classes, do you generally just use
> a simple symbol, or concatenate strings to convey more details? This last
> seems somehow a bad idea... but maybe if it's never caught it's not so
> relevant?
> >
> > I don't understand exactly what you mean... if you are suggesting using
> error codes over exceptions, no, that is not may point. Exceptions are the
> right tool to get rid of the repeated/error prone code you create when using
> error codes, there is not doubt about it.
> > What I'm saying is that from the handling point of view you only need to
> identify the exception to handle, and matching the class of the exception
> with identifying the exception is not the only way (I showed another way in
> a previous mail).
> > Also, categorizing exception types using subclassing does not seem to be
> a good idea either... it is common use now, but that does not mean it is
> good. Sometimes you want to categorize exceptions in a different way that
> your exception class hierarchy forces you, and when that happens it is
> really a pain.
> But right now that is possible by concatenating Exceptions, generating
> ExceptionSets, which you could even generate upfront, so complexity-wise it
> is the same as using symbols as identifiers in a generic Exception class.

yes of course, but you still have the super-class relationship... anyway,
this is not the main issue

> But I agree finding the right balance of how many exception classes to use
> is not easy. However, we are still far from that in Pharo..., even worse,
> since no one uses explicit error classes no one uses them.

As I said, I used them in a system and the conclusion was that you don't
need them... a program can do little when an exception is throw to fix the
problem (but in very small cases)...  they are basically to inform the user
that something went wrong and having a good description is more important
than having a big exception hierarchy.

> And certainly there should be another way to catch errors than just by
> relying on the type / class. Sometimes it would be nice to be able to catch
> errors depending on the place they were thrown,  for instance only handle
> exceptions thrown in my own methods / my package...

yes, that is completely true... I would be great to have a mechanism where
you could automatically convert exception while the pass subsystems/layers
bounderies too... that is a great research topic I think

> And concerning the IDE, we need a lot of improvements there, the current
> design and functionality in Pharo at least, resembles more a system from the
> 70'ies than a more recent ide.

*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/a14d73e3/attachment.htm>

More information about the Pharo-project mailing list