On Thu, Apr 14, 2011 at 10:37 AM, Camillo Bruni <[email protected]>wrote:
> > On 2011-04-14, at 14:19, Hernan Wilkinson wrote: > > > > > > > On Thu, Apr 14, 2011 at 9:08 AM, Toon Verwaest <[email protected]> > 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: [email protected] site: http://www.10Pines.com <http://www.10pines.com/>*
