[Pharo-project] Improving Pharo's Exception Hierarchy

Camillo Bruni camillo.bruni at inria.fr
Thu Apr 14 15:37:31 CEST 2011


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.

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. 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...

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.


More information about the Pharo-project mailing list