- Pharo-dev - lists.pharo.org

Re: [Pharo-project] new transcript :(

by Fernando Olivero

Read only form, that's displayed surrounded by a system window. Evaluate: Transcript clear. I worked on some of the complaints, mainly by Igor on the previous email. Maybe i should also make the TranscriptMorph to use a standard text widget again. pd: please take a look at this issue: ISSUE 3948: I've replaced the Transcript class with an equal TranscriptModel instance, reverting to the use of a global Transcript, according to Igors suggestion. I also modified a bit the TranscriptMorph, to denote the read-only nature of the text. (Igor suggested to be able to select the text as well, not yet there); and changed all the uses ( in Core) to go through StandardToolSet openTranscript. On Wed, Apr 13, 2011 at 5:18 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > hi guys > > why there is no scrollbar on the widgets? > why I cannot select text there? > why I cannot delete text there? > > Stef > >

April 14, 2011

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

by Daniel Lyons

On Apr 13, 2011, at 5:00 PM, Dale Henrichs wrote: > 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" I hope (as an outsider) that this advice is taken seriously during this important refactoring effort. Designing the hierarchy is very much a what-color-should-the-bike-shed-be question. Usually the way it plays out on in day-to-day use is not gratitude towards the benevolent API designer for having provided such precise and helpful exception classes or rage towards the careless API designer for making them so unhelpful. No, In my experience it is much more likely to be, swearing at the API designer for having made exception handling an important (but substantially less discoverable) part of the API that must be mastered alongside the ordinary message protocol. A lesson from Java is that if you provide a rich, complex exception hierarchy with lots of specific exceptions, people will feel like they should be using them, even if they're never used in the system, poorly defined, or represent too broad a category (I'm looking at you, IllegalStateException!) â Daniel Lyons

April 14, 2011

Re: [Pharo-project] PostgresSQL - ODBC

by Schwab,Wilhelm K

You didn't miss anything that I can see - just passing along something I wish I had found in writing a few hours ago =:0 I was motivated to get ODBC working specifically because it has worked well for me too. At least in the version of ODBCLibrary that I am using, there is some room to grow with respect to discarding old objects on session start, and I continue to think we need (perhaps optional) logging to failures to load, failures to open ports, etc. Any time the vm translates something that we pass to it (name into path to library, port name into number or vice versa), there should be a way to log it w/o having to recompile the vm. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Benoit St-Jean [bstjean(a)yahoo.com] Sent: Wednesday, April 13, 2011 7:07 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] PostgresSQL - ODBC I missed the start of the thread but I've been using PostgreSQL and Pharo for quite a while on Windows XP (both PostgreSQL & Pharo). So far, Pharo is rock-solid with ODBC, at least on WinXP ! ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: "Pharo-project(a)lists.gforge.inria.fr" <Pharo-project(a)lists.gforge.inria.fr> Sent: Wed, April 13, 2011 7:00:13 PM Subject: [Pharo-project] PostgresSQL - ODBC Hello all, I have been successful in using unixODBC and a Postgres driver to communicate with what I believe is an encrypting server (at least according to pgadmin). I did lots of things, such as building the driver from source, that might have been critical, but I strongly suspect that the key to success was simply using ServerName in place of Server in .odbc.ini. FWIW. Bill

April 14, 2011

Re: [Pharo-project] PostgresSQL - ODBC

by Benoit St-Jean

I missed the start of the thread but I've been using PostgreSQL and Pharo for quite a while on Windows XP (both PostgreSQL & Pharo). So far, Pharo is rock-solid with ODBC, at least on WinXP ! ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: "Pharo-project(a)lists.gforge.inria.fr" <Pharo-project(a)lists.gforge.inria.fr> Sent: Wed, April 13, 2011 7:00:13 PM Subject: [Pharo-project] PostgresSQL - ODBC Hello all, I have been successful in using unixODBC and a Postgres driver to communicate with what I believe is an encrypting server (at least according to pgadmin). I did lots of things, such as building the driver from source, that might have been critical, but I strongly suspect that the key to success was simply using ServerName in place of Server in .odbc.ini. FWIW. Bill

April 14, 2011

[Pharo-project] PostgresSQL - ODBC

by Schwab,Wilhelm K

Hello all, I have been successful in using unixODBC and a Postgres driver to communicate with what I believe is an encrypting server (at least according to pgadmin). I did lots of things, such as building the driver from source, that might have been critical, but I strongly suspect that the key to success was simply using ServerName in place of Server in .odbc.ini. FWIW. Bill

April 14, 2011

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

by Dale Henrichs

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

April 14, 2011

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

by Nicolas Cellier

Reusing is important because it means reducing the number of concepts and reducing the complexity. Once we fail to manage this complexity, the image grows exponentially: two times more classes means half chance to find matching information, and twice to reinvent. But of course, that does not mean Classes must not be used. Create KeyNotFound if you need it, and let it carry precious information. Nicolas 2011/4/13 Toon Verwaest <toon.verwaest(a)gmail.com>: > 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. > > 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? > > 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 > > although the second one gives you all the contextual information that the > first one misses. > > What I mean mostly: what about trying to figure out why you want to avoid > decent exception classes and tackling that problem? > 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? > > cheers, > Toon > > On 04/13/2011 11:31 PM, Dale Henrichs wrote: >> >> By managing the class hierarchy: >> >> Â Imagine trying to find meaningful exception classes in a class >> Â hierarchy of 10,000 classes with significant nesting vs finding a >> Â meaningful class in a hierarchy of 10 classes ... at what point does >> Â the hierarchy get out of hand? >> >> >> I think GemStone had 600 some unique errors and that was pared down to <30 >> Exception classes with reason codes... >> >> It's a matter of practicality...I would think that somewhere around 100 >> classes the hierarchy starts to become very tedious to understand even for >> those trying to find the right place to insert there brand spanking new >> exception class. >> >> 99% of exception handlers will _use_ Error_ anyway, so the exception >> hierarchy will be largely ignored by most folks, especially if it is large >> an unwieldly. >> >> 100 small classes that serve a real purpose and have explicit exception >> handlers written using every one of them, well then by god! 100 classes are >> absolutely called for. >> >> To me this is different than 100 places where I signal an exception ... do >> really need a different exception class for each of the 100 signalling >> sites? What if there are no handlers written for any of them? Like I said, >> if there are legitimate need to handle an exception, then there is a >> legitimate need to create an exception class, but if I have 5 different >> error conditions, but I will have a single exception handler for all 5 >> conditions, _should_ I create 5 classes or 1 class with some state to >> disambiguate? >> >> If your answer is "It depends...", then you will understand what I am >> saying:) >> >> Dale >> >> On 04/13/2011 02:01 PM, Toon Verwaest wrote: >>> >>> I find the "managing the exception hierarchy" a bit strange... Do you >>> really have to manage anything more than just normal classes? Every >>> exception is related to a specific part of your code, just like other >>> classes. What's wrong with creating hundreds of small classes wherever >>> it's necessary? You might save a tiny bit of memory by using error codes >>> or symbols, but I don't really see much more of a gain there, while you >>> do gain from proper objects. >>> >>> Being clear and modeling properly generally pays off in the long run. >>> And the bit of runtime memory you save isn't really worth your while... >>> >>> Or am I missing something else? I didn't really follow the whole >>> conversation in-depth. >>> >>> cheers, >>> Toon >>> >>> On 04/13/2011 09:54 PM, Dale Henrichs wrote: >>>> >>>> Camillo, >>>> >>>> Hey, I _am_ old, but not _that_ old:) ... There are a couple of things >>>> that were invented in the Stone Age that have survived to today, so >>>> old ideas are not immediately bad, because they are old:) >>>> >>>> It feels like you are creating classes that are not much more than >>>> symbols ... >>>> >>>> I am not one to shy away from using classes when they are called for, >>>> but I am just making a practicality point ... we don't have a unique >>>> class for each character in the alphabet, but we could....we could >>>> have a unique class for every possible error condition or not ... >>>> >>>> I think it is simply a practical answer... >>>> >>>> I do maintain that you _should_ use some sort of test along the lines >>>> of: "Will anyone ever need to write a handler for the exception?" in >>>> your criteria for deciding when to create a class and when to use >>>> something like a "reason code" to disambiguate the signalling site... >>>> >>>> Dale >>>> >>>> On 04/13/2011 12:32 PM, Camillo Bruni wrote: >>>>> >>>>> Perfect, I ll be there to bang heads ;). >>>>> >>>>> So without "Exception" pre- or suffix seems to be nice. However I >>>>> don't see the need of using symbols over real classes. This feels >>>>> indeed like going to stone age of error handling, thats what you have >>>>> polymorphism and ExceptionSets for. >>>>> >>>>> Anyway, the main idea is to make single exceptions recognizable and >>>>> not just use one single, basically meaningless, exception type. >>>>> >>>>> best regards, Camillo Bruni >>>>> >>>>> >>>>> On 2011-04-13, at 21:22, Sven Van Caekenberghe wrote: >>>>> >>>>>> Thanks a lot everybody for the reactions, this could become a nice >>>>>> discussion next Friday. All points raised are valid, I would like >>>>>> simple names and a compact multipurpose hierarchy too. >>>>>> >>>>>> On 13 Apr 2011, at 19:39, Dale Henrichs wrote: >>>>>> >>>>>>> Some thoughts from an old man (started programming before >>>>>>> exceptions of any kind were available:) ... >>>>>>> >>>>>>> In the old days, error numbers had a place in the universe ... >>>>>>> error numbers of a certain range indicated specific errors and >>>>>>> the "error handlers" could check for a range or a specific error >>>>>>> ... >>>>>>> >>>>>>> Today I think there is still a place for the notion of "error >>>>>>> numbers". >>>>>>> >>>>>>> In Smalltalk I would use Symbols instead of numbers, but the idea >>>>>>> would be to use a concrete exception class to identify broad >>>>>>> categories of error conditions (i.e., FileStreamError) and a >>>>>>> symbolic "reason code" to indicate the specific error (i.e., >>>>>>> #fileDoesNotExist, #fileExists, #cannotDelete, etc.), that way an >>>>>>> error handler can be written for FileStreamError and then >>>>>>> specific action take with respect to which "reason code" is >>>>>>> involved, if such action is needed. >>>>>>> >>>>>>> The main advantage of using reasonCodes over using a "class per >>>>>>> error condition" is that you can reduce the size of the Exception >>>>>>> hierarchy to a manageable size (GemStone has hundreds of error >>>>>>> conditions, so we've resorted to using "reason codes" to manage >>>>>>> the size of the hierarchy). >>>>>>> >>>>>>> As Hernan hints, more often than not it is important to be very >>>>>>> specific about the error condition when signalling an error (a >>>>>>> unique error message per "per reason code" would be desirable), >>>>>>> but the there are very few places where the handler is going to >>>>>>> be that specific ... >>>>>>> >>>>>>> In other words, if it is likely that programmers in the course of >>>>>>> using an application will be writing specific error handlers to >>>>>>> distinguish between the KeyNotFound and ValueNotFound condition, >>>>>>> then classes should be created, otherwise, the NotFoundException >>>>>>> could be implemented with three reason codes: #keyNotFound, >>>>>>> #valueNotFound, and #elementNotFound and you'd get the best of >>>>>>> both worlds, explicit information at the signalling site and a >>>>>>> much smaller and more manageable Exception class hierarchy. >>>>>>> >>>>>>> Dale >>>>>>> >>>>>>> On 04/13/2011 10:15 AM, Hernan Wilkinson wrote: >>>>>>>> >>>>>>>> I think it is not a good idea to use the prefix Exception. We >>>>>>>> do not use the word "exception" in real life, so we should not >>>>>>>> do it on our systems. About the proposed hierarchy, the problem >>>>>>>> with having specific exceptions is that they are important for >>>>>>>> those who catch them, not for those who signal them. For >>>>>>>> example, besides the name, what is the difference between >>>>>>>> KeyNotFound or ValueNotFound? none. So, I think that the >>>>>>>> exception hierarchy should be grown from it uses, not created >>>>>>>> based on how or where they are signaled. >>>>>>>> >>>>>>>> my 2 cents :-) >>>>>>>> >>>>>>>> On Wed, Apr 13, 2011 at 1:55 PM, Miguel >>>>>>>> CobÃ¡<miguel.coba(a)gmail.com<mailto:miguel.coba@gmail.com>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> El miÃ©, 13-04-2011 a las 14:52 +0200, Camillo Bruni escribiÃ³: >>>>>>>> >>>>>>>>> And as Mariano pointed out, there should be a convention on >>>>>>>>> the naming: I am still not sure about suffixing the exception >>>>>>>>> classes >>>>>>>> >>>>>>>> with >>>>>>>>> >>>>>>>>> "Exception", but I guess this is a good thing to do. Though >>>>>>>>> I >>>>>>>> >>>>>>>> must say >>>>>>>>> >>>>>>>>> that I omitted it so far ;) and just put the verb there, but >>>>>>>>> that can be easily changed. >>>>>>>> >>>>>>>> I would say no to suffixes. Analogous to announcements, they >>>>>>>> shouldn't have the suffix. The name should be descriptive >>>>>>>> enough and intention revealing that the suffix isn't needed in >>>>>>>> most cases. For example, I think that >>>>>>>> >>>>>>>> DividedByZero >>>>>>>> >>>>>>>> is better than >>>>>>>> >>>>>>>> DividedByZeroException >>>>>>>> >>>>>>>> and no information is lost with the sorter name. Instead, >>>>>>>> DivideByZero isn't clear enough to indicate that is a event >>>>>>>> that happened. >>>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz >>>>>>>> http://miguel.leugim.com.mx >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- *HernÃ¡n Wilkinson Agile Software Development, Teaching& >>>>>>>> Coaching Mobile: +54 - 911 - 4470 - 7207 email: >>>>>>>> hernan.wilkinson(a)10Pines.com site: >>>>>>>> http://www.10Pines.com<http://www.10pines.com/>* >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > >

April 14, 2011

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

by Toon Verwaest

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. 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? 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 although the second one gives you all the contextual information that the first one misses. What I mean mostly: what about trying to figure out why you want to avoid decent exception classes and tackling that problem? 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? cheers, Toon On 04/13/2011 11:31 PM, Dale Henrichs wrote: > By managing the class hierarchy: > > Imagine trying to find meaningful exception classes in a class > hierarchy of 10,000 classes with significant nesting vs finding a > meaningful class in a hierarchy of 10 classes ... at what point does > the hierarchy get out of hand? > > > I think GemStone had 600 some unique errors and that was pared down to > <30 Exception classes with reason codes... > > It's a matter of practicality...I would think that somewhere around > 100 classes the hierarchy starts to become very tedious to understand > even for those trying to find the right place to insert there brand > spanking new exception class. > > 99% of exception handlers will _use_ Error_ anyway, so the exception > hierarchy will be largely ignored by most folks, especially if it is > large an unwieldly. > > 100 small classes that serve a real purpose and have explicit > exception handlers written using every one of them, well then by god! > 100 classes are absolutely called for. > > To me this is different than 100 places where I signal an exception > ... do really need a different exception class for each of the 100 > signalling sites? What if there are no handlers written for any of > them? Like I said, if there are legitimate need to handle an > exception, then there is a legitimate need to create an exception > class, but if I have 5 different error conditions, but I will have a > single exception handler for all 5 conditions, _should_ I create 5 > classes or 1 class with some state to disambiguate? > > If your answer is "It depends...", then you will understand what I am > saying:) > > Dale > > On 04/13/2011 02:01 PM, Toon Verwaest wrote: >> I find the "managing the exception hierarchy" a bit strange... Do you >> really have to manage anything more than just normal classes? Every >> exception is related to a specific part of your code, just like other >> classes. What's wrong with creating hundreds of small classes wherever >> it's necessary? You might save a tiny bit of memory by using error codes >> or symbols, but I don't really see much more of a gain there, while you >> do gain from proper objects. >> >> Being clear and modeling properly generally pays off in the long run. >> And the bit of runtime memory you save isn't really worth your while... >> >> Or am I missing something else? I didn't really follow the whole >> conversation in-depth. >> >> cheers, >> Toon >> >> On 04/13/2011 09:54 PM, Dale Henrichs wrote: >>> Camillo, >>> >>> Hey, I _am_ old, but not _that_ old:) ... There are a couple of things >>> that were invented in the Stone Age that have survived to today, so >>> old ideas are not immediately bad, because they are old:) >>> >>> It feels like you are creating classes that are not much more than >>> symbols ... >>> >>> I am not one to shy away from using classes when they are called for, >>> but I am just making a practicality point ... we don't have a unique >>> class for each character in the alphabet, but we could....we could >>> have a unique class for every possible error condition or not ... >>> >>> I think it is simply a practical answer... >>> >>> I do maintain that you _should_ use some sort of test along the lines >>> of: "Will anyone ever need to write a handler for the exception?" in >>> your criteria for deciding when to create a class and when to use >>> something like a "reason code" to disambiguate the signalling site... >>> >>> Dale >>> >>> On 04/13/2011 12:32 PM, Camillo Bruni wrote: >>>> Perfect, I ll be there to bang heads ;). >>>> >>>> So without "Exception" pre- or suffix seems to be nice. However I >>>> don't see the need of using symbols over real classes. This feels >>>> indeed like going to stone age of error handling, thats what you have >>>> polymorphism and ExceptionSets for. >>>> >>>> Anyway, the main idea is to make single exceptions recognizable and >>>> not just use one single, basically meaningless, exception type. >>>> >>>> best regards, Camillo Bruni >>>> >>>> >>>> On 2011-04-13, at 21:22, Sven Van Caekenberghe wrote: >>>> >>>>> Thanks a lot everybody for the reactions, this could become a nice >>>>> discussion next Friday. All points raised are valid, I would like >>>>> simple names and a compact multipurpose hierarchy too. >>>>> >>>>> On 13 Apr 2011, at 19:39, Dale Henrichs wrote: >>>>> >>>>>> Some thoughts from an old man (started programming before >>>>>> exceptions of any kind were available:) ... >>>>>> >>>>>> In the old days, error numbers had a place in the universe ... >>>>>> error numbers of a certain range indicated specific errors and >>>>>> the "error handlers" could check for a range or a specific error >>>>>> ... >>>>>> >>>>>> Today I think there is still a place for the notion of "error >>>>>> numbers". >>>>>> >>>>>> In Smalltalk I would use Symbols instead of numbers, but the idea >>>>>> would be to use a concrete exception class to identify broad >>>>>> categories of error conditions (i.e., FileStreamError) and a >>>>>> symbolic "reason code" to indicate the specific error (i.e., >>>>>> #fileDoesNotExist, #fileExists, #cannotDelete, etc.), that way an >>>>>> error handler can be written for FileStreamError and then >>>>>> specific action take with respect to which "reason code" is >>>>>> involved, if such action is needed. >>>>>> >>>>>> The main advantage of using reasonCodes over using a "class per >>>>>> error condition" is that you can reduce the size of the Exception >>>>>> hierarchy to a manageable size (GemStone has hundreds of error >>>>>> conditions, so we've resorted to using "reason codes" to manage >>>>>> the size of the hierarchy). >>>>>> >>>>>> As Hernan hints, more often than not it is important to be very >>>>>> specific about the error condition when signalling an error (a >>>>>> unique error message per "per reason code" would be desirable), >>>>>> but the there are very few places where the handler is going to >>>>>> be that specific ... >>>>>> >>>>>> In other words, if it is likely that programmers in the course of >>>>>> using an application will be writing specific error handlers to >>>>>> distinguish between the KeyNotFound and ValueNotFound condition, >>>>>> then classes should be created, otherwise, the NotFoundException >>>>>> could be implemented with three reason codes: #keyNotFound, >>>>>> #valueNotFound, and #elementNotFound and you'd get the best of >>>>>> both worlds, explicit information at the signalling site and a >>>>>> much smaller and more manageable Exception class hierarchy. >>>>>> >>>>>> Dale >>>>>> >>>>>> On 04/13/2011 10:15 AM, Hernan Wilkinson wrote: >>>>>>> I think it is not a good idea to use the prefix Exception. We >>>>>>> do not use the word "exception" in real life, so we should not >>>>>>> do it on our systems. About the proposed hierarchy, the problem >>>>>>> with having specific exceptions is that they are important for >>>>>>> those who catch them, not for those who signal them. For >>>>>>> example, besides the name, what is the difference between >>>>>>> KeyNotFound or ValueNotFound? none. So, I think that the >>>>>>> exception hierarchy should be grown from it uses, not created >>>>>>> based on how or where they are signaled. >>>>>>> >>>>>>> my 2 cents :-) >>>>>>> >>>>>>> On Wed, Apr 13, 2011 at 1:55 PM, Miguel >>>>>>> CobÃ¡<miguel.coba(a)gmail.com<mailto:miguel.coba@gmail.com>> >>>>>>> wrote: >>>>>>> >>>>>>> El miÃ©, 13-04-2011 a las 14:52 +0200, Camillo Bruni escribiÃ³: >>>>>>> >>>>>>>> And as Mariano pointed out, there should be a convention on >>>>>>>> the naming: I am still not sure about suffixing the exception >>>>>>>> classes >>>>>>> with >>>>>>>> "Exception", but I guess this is a good thing to do. Though >>>>>>>> I >>>>>>> must say >>>>>>>> that I omitted it so far ;) and just put the verb there, but >>>>>>>> that can be easily changed. >>>>>>> >>>>>>> I would say no to suffixes. Analogous to announcements, they >>>>>>> shouldn't have the suffix. The name should be descriptive >>>>>>> enough and intention revealing that the suffix isn't needed in >>>>>>> most cases. For example, I think that >>>>>>> >>>>>>> DividedByZero >>>>>>> >>>>>>> is better than >>>>>>> >>>>>>> DividedByZeroException >>>>>>> >>>>>>> and no information is lost with the sorter name. Instead, >>>>>>> DivideByZero isn't clear enough to indicate that is a event >>>>>>> that happened. >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz >>>>>>> http://miguel.leugim.com.mx >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- *HernÃ¡n Wilkinson Agile Software Development, Teaching& >>>>>>> Coaching Mobile: +54 - 911 - 4470 - 7207 email: >>>>>>> hernan.wilkinson(a)10Pines.com site: >>>>>>> http://www.10Pines.com<http://www.10pines.com/>* >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >

April 13, 2011

Re: [Pharo-project] Meanwhile, at another vm

by Stefan Marr

On 13 Apr 2011, at 23:27, GÃ¶ran Krampe wrote: > On 04/13/2011 11:15 PM, Mariano Martinez Peck wrote: >> On Wed, Apr 13, 2011 at 11:06 PM, Dave Mason <dmason(a)mason-rose.ca >> "We will also investigate support for hotswapping, the capability to >> modify the structure of classes at run time." >> >> So, yes, they planned to "investigate" a version of become: >> >> >> How is that phrase related to #become: ? Modyfing the structure of a >> class at runtime has nothing to do with a #become: > > It depends. If "modify structure" means "modifying methods" then indeed it has little to do with become:. But if it means "changing the memory layout of the class by for example adding ivars" then it has to do with become: because it is needed to do instance migration from the old class to the new class. There is no need for guessing, Google knows the answer: http://download.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#Redefine… "Instances of the redefined class are not affected -- fields retain their previous values. Tags on the instances are also unaffected." "The redefinition may change method bodies, the constant pool and attributes. The redefinition must not add, remove or rename fields or methods, change the signatures of methods, change modifiers, or change inheritance. These restrictions may be lifted in future versions. "... -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

April 13, 2011

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

by Dale Henrichs

Nicolas, Well put:) Dale On 04/13/2011 02:20 PM, Nicolas Cellier wrote: > What's wrong is simple to explain: Your image is a namespace. The more > names you have, the more difficult it is to apprehend, understand and > reuse. > > Wait, wait, wait, you might say, whether I use Symbols or Class names, > there are always the same number of names at the end. > > Yes, but what makes the big difference is the IDE. What we see thru > this IDE is either: > - a view by package or protocol > - a hierarchical view. > > How to find if a specific Exception exists, what it's name is ? > By now, I find package names misleading, because not very uniform. > Even if uniformized, it's not always obvious where to search for. > Plus, there are a lot of packages. > The hierarchical view would be more natural, but is to my taste > unusable above 30 items. I find current Exception hierarchy > unfriendly. > So the idea to use a double classification, a quite generic exception > name like FileError and a specialization "code" does make sense. > > You must understand this, when our neurons were younger, we learnt > Smalltalk with a ~300 classes image. What a great pleasure to be able > to embrace the whole system ! > Now our older neurons must remember about 8x more... > So we appreciate the inflation with a different scale. > > Nicolas > > 2011/4/13 Toon Verwaest<toon.verwaest(a)gmail.com>: >> I find the "managing the exception hierarchy" a bit strange... Do you really >> have to manage anything more than just normal classes? Every exception is >> related to a specific part of your code, just like other classes. What's >> wrong with creating hundreds of small classes wherever it's necessary? You >> might save a tiny bit of memory by using error codes or symbols, but I don't >> really see much more of a gain there, while you do gain from proper objects. >> >> Being clear and modeling properly generally pays off in the long run. And >> the bit of runtime memory you save isn't really worth your while... >> >> Or am I missing something else? I didn't really follow the whole >> conversation in-depth. >> >> cheers, >> Toon >> >> On 04/13/2011 09:54 PM, Dale Henrichs wrote: >>> >>> Camillo, >>> >>> Hey, I _am_ old, but not _that_ old:) ... There are a couple of things >>> that were invented in the Stone Age that have survived to today, so old >>> ideas are not immediately bad, because they are old:) >>> >>> It feels like you are creating classes that are not much more than symbols >>> ... >>> >>> I am not one to shy away from using classes when they are called for, but >>> I am just making a practicality point ... we don't have a unique class for >>> each character in the alphabet, but we could....we could have a unique class >>> for every possible error condition or not ... >>> >>> I think it is simply a practical answer... >>> >>> I do maintain that you _should_ use some sort of test along the lines of: >>> "Will anyone ever need to write a handler for the exception?" in your >>> criteria for deciding when to create a class and when to use something like >>> a "reason code" to disambiguate the signalling site... >>> >>> Dale >>> >>> On 04/13/2011 12:32 PM, Camillo Bruni wrote: >>>> >>>> Perfect, I ll be there to bang heads ;). >>>> >>>> So without "Exception" pre- or suffix seems to be nice. However I >>>> don't see the need of using symbols over real classes. This feels >>>> indeed like going to stone age of error handling, thats what you have >>>> polymorphism and ExceptionSets for. >>>> >>>> Anyway, the main idea is to make single exceptions recognizable and >>>> not just use one single, basically meaningless, exception type. >>>> >>>> best regards, Camillo Bruni >>>> >>>> >>>> On 2011-04-13, at 21:22, Sven Van Caekenberghe wrote: >>>> >>>>> Thanks a lot everybody for the reactions, this could become a nice >>>>> discussion next Friday. All points raised are valid, I would like >>>>> simple names and a compact multipurpose hierarchy too. >>>>> >>>>> On 13 Apr 2011, at 19:39, Dale Henrichs wrote: >>>>> >>>>>> Some thoughts from an old man (started programming before >>>>>> exceptions of any kind were available:) ... >>>>>> >>>>>> In the old days, error numbers had a place in the universe ... >>>>>> error numbers of a certain range indicated specific errors and >>>>>> the "error handlers" could check for a range or a specific error >>>>>> ... >>>>>> >>>>>> Today I think there is still a place for the notion of "error >>>>>> numbers". >>>>>> >>>>>> In Smalltalk I would use Symbols instead of numbers, but the idea >>>>>> would be to use a concrete exception class to identify broad >>>>>> categories of error conditions (i.e., FileStreamError) and a >>>>>> symbolic "reason code" to indicate the specific error (i.e., >>>>>> #fileDoesNotExist, #fileExists, #cannotDelete, etc.), that way an >>>>>> error handler can be written for FileStreamError and then >>>>>> specific action take with respect to which "reason code" is >>>>>> involved, if such action is needed. >>>>>> >>>>>> The main advantage of using reasonCodes over using a "class per >>>>>> error condition" is that you can reduce the size of the Exception >>>>>> hierarchy to a manageable size (GemStone has hundreds of error >>>>>> conditions, so we've resorted to using "reason codes" to manage >>>>>> the size of the hierarchy). >>>>>> >>>>>> As Hernan hints, more often than not it is important to be very >>>>>> specific about the error condition when signalling an error (a >>>>>> unique error message per "per reason code" would be desirable), >>>>>> but the there are very few places where the handler is going to >>>>>> be that specific ... >>>>>> >>>>>> In other words, if it is likely that programmers in the course of >>>>>> using an application will be writing specific error handlers to >>>>>> distinguish between the KeyNotFound and ValueNotFound condition, >>>>>> then classes should be created, otherwise, the NotFoundException >>>>>> could be implemented with three reason codes: #keyNotFound, >>>>>> #valueNotFound, and #elementNotFound and you'd get the best of >>>>>> both worlds, explicit information at the signalling site and a >>>>>> much smaller and more manageable Exception class hierarchy. >>>>>> >>>>>> Dale >>>>>> >>>>>> On 04/13/2011 10:15 AM, Hernan Wilkinson wrote: >>>>>>> >>>>>>> I think it is not a good idea to use the prefix Exception. We >>>>>>> do not use the word "exception" in real life, so we should not >>>>>>> do it on our systems. About the proposed hierarchy, the problem >>>>>>> with having specific exceptions is that they are important for >>>>>>> those who catch them, not for those who signal them. For >>>>>>> example, besides the name, what is the difference between >>>>>>> KeyNotFound or ValueNotFound? none. So, I think that the >>>>>>> exception hierarchy should be grown from it uses, not created >>>>>>> based on how or where they are signaled. >>>>>>> >>>>>>> my 2 cents :-) >>>>>>> >>>>>>> On Wed, Apr 13, 2011 at 1:55 PM, Miguel >>>>>>> CobÃ¡<miguel.coba(a)gmail.com<mailto:miguel.coba@gmail.com>> >>>>>>> wrote: >>>>>>> >>>>>>> El miÃ©, 13-04-2011 a las 14:52 +0200, Camillo Bruni escribiÃ³: >>>>>>> >>>>>>>> And as Mariano pointed out, there should be a convention on >>>>>>>> the naming: I am still not sure about suffixing the exception >>>>>>>> classes >>>>>>> >>>>>>> with >>>>>>>> >>>>>>>> "Exception", but I guess this is a good thing to do. Though >>>>>>>> I >>>>>>> >>>>>>> must say >>>>>>>> >>>>>>>> that I omitted it so far ;) and just put the verb there, but >>>>>>>> that can be easily changed. >>>>>>> >>>>>>> I would say no to suffixes. Analogous to announcements, they >>>>>>> shouldn't have the suffix. The name should be descriptive >>>>>>> enough and intention revealing that the suffix isn't needed in >>>>>>> most cases. For example, I think that >>>>>>> >>>>>>> DividedByZero >>>>>>> >>>>>>> is better than >>>>>>> >>>>>>> DividedByZeroException >>>>>>> >>>>>>> and no information is lost with the sorter name. Instead, >>>>>>> DivideByZero isn't clear enough to indicate that is a event >>>>>>> that happened. >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz >>>>>>> http://miguel.leugim.com.mx >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- *HernÃ¡n Wilkinson Agile Software Development, Teaching& >>>>>>> Coaching Mobile: +54 - 911 - 4470 - 7207 email: >>>>>>> hernan.wilkinson(a)10Pines.com site: >>>>>>> http://www.10Pines.com<http://www.10pines.com/>* >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >> >

April 13, 2011