- Pharo-dev - lists.pharo.org

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

by Henrik Sperre Johansen

On 14.04.2011 20:52, Dale Henrichs wrote: > Stef, > > For rangeError the code would look like this: > > [ > (NumericError new) > reason: #rangeError; > signal: 'access out of bounds' > ] > on: NumericError > do: [:ex | > ex reasonCode == #rangeError > ifTrue: [ "do your thang" ] > ifFalse: [ ex pass ]]. > > Dale Why not use #tag, which is already ANSI? Cheers, Henry

April 14, 2011

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

by Dale Henrichs

On 04/14/2011 11:38 AM, Sven Van Caekenberghe wrote: > Dale, > > I think I understand some of your points, there based on valid concerns. We should end up with a minimal set of exceptions. The current set was not that large IMHO. But here and there some simplifications are possible. > > Thanks for submitting a concrete alternative hierarchy. > > However, it feels as if the reasons between using a class and a selector are a bit arbitrary. I can't make sense out of it. > > Another thing that hasn't been discussed so far is what data should go in each exception. > > This has to be done on a blackboard with a couple of people. And it won't be finished in one go either, far from it. > > I'll print out your hierarchy as well ! > > Sven Sven, The names with leading $# were intended to be reasonCodes and with no leading $# a class name ... When I editted the list I wasn't thinking very hard:), but I made a best guess based on what I thought the name entailed (and we had touched on some of the same things in our GemStone discussions)...So I wouldn't put much weight on the specifics in my suggestions, I think you get the general idea ... the more important information was in my suggested guidelines ... the decisions should be driven by the needs of the existing Pharo code base both the core and the applications written against the core ... BTW, I fully support what you are trying to do and building a good usable Exception hierarchy is important ... I just wanted to inject a suggestion or two for consideration... Dale

April 14, 2011

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

by Dale Henrichs

Stef, For rangeError the code would look like this: [ (NumericError new) reason: #rangeError; signal: 'access out of bounds' ] on: NumericError do: [:ex | ex reasonCode == #rangeError ifTrue: [ "do your thang" ] ifFalse: [ ex pass ]]. Dale On 04/14/2011 11:13 AM, StÃ©phane Ducasse wrote: > Dale > > so it means that I write what? > > [] on: NumericError do: [:ex | ] > > how do I access the rangeError? > > >>> >> >> Using Sven's hierachy as a starting point and taking some cues from the GemStone exception hierarchy, I would suggest the following (names atarting with # are reasonCodes in the namespace of the parent exception class, instead of a unique class): >> >> Exception (messageText reasonCode) >> Abort >> Error >> NumericError >> #floatingPointException >> #rangeError >> #naNError >> ZeroDivide (dividend) >> FileStreamException (fileName) >> #fileDoesNotExistException >> #fileExistsException (fileClass) >> #cannotDeleteFileException >> #fileWriteError >> #fileReadError ** >> #fileClosedException ** >> #cannotAccessFileException ** >> #readonlyFileException ** >> MessageNotUnderstood (message, receiver) >> #nonBooleanReceiver (object) >> OutOfMemory< handlers?> >> ControlInterrupt >> Halt >> AssertionFailure >> BreakPoint >> CompileError >> SyntaxError ** !exists! (input, position) >> #numberFormatException ** >> #headlessError ** >> TimedOut ** (object, operation, timeout) >> VerificationException >> IllegalOperation ** (operation, object) >> #sizeMismatch (objects) >> #subclassResponsibility ** (message, receiver) >> #notYetImplemented ** (message, receiver) >> #cannotInstanciate ** (class) >> #readOnlyObject ** (object) >> OutOfFreeSpace **<handlers?> >> #invalidArgument ** (message, receiver, argument) >> #notIndexable ** (object) >> #noKeyedAccess ** (object) >> #nonIntegerIndex ** (receiver, index) >> #subscriptOutOfBounds ** (receiver, index, from, to) >> NotFoundException ** (receiver, object) >> #keyNotFound ** >> #valueNotFound ** >> #elementNotFound ** >> StreamException (stream) >> #positionError ** (index, from, to) >> EndOfStream ** >> #beginOfStream ** >> >> Notification >> Admonition >> LowMemory **<this should be a notification not an error> >> > >

April 14, 2011

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

by Sven Van Caekenberghe

Dale, I think I understand some of your points, there based on valid concerns. We should end up with a minimal set of exceptions. The current set was not that large IMHO. But here and there some simplifications are possible. Thanks for submitting a concrete alternative hierarchy. However, it feels as if the reasons between using a class and a selector are a bit arbitrary. I can't make sense out of it. Another thing that hasn't been discussed so far is what data should go in each exception. This has to be done on a blackboard with a couple of people. And it won't be finished in one go either, far from it. I'll print out your hierarchy as well ! Sven On 14 Apr 2011, at 18:07, Dale Henrichs wrote: > Using Sven's hierachy as a starting point and taking some cues from the GemStone exception hierarchy, I would suggest the following (names atarting with # are reasonCodes in the namespace of the parent exception class, instead of a unique class): > > Exception (messageText reasonCode) > Abort > Error > NumericError > #floatingPointException > #rangeError > #naNError > ZeroDivide (dividend) > FileStreamException (fileName) > #fileDoesNotExistException > #fileExistsException (fileClass) > #cannotDeleteFileException > #fileWriteError > #fileReadError ** > #fileClosedException ** > #cannotAccessFileException ** > #readonlyFileException ** > MessageNotUnderstood (message, receiver) > #nonBooleanReceiver (object) > OutOfMemory < handlers?> > ControlInterrupt > Halt > AssertionFailure > BreakPoint > CompileError > SyntaxError ** !exists! (input, position) > #numberFormatException ** > #headlessError ** > TimedOut ** (object, operation, timeout) > VerificationException > IllegalOperation ** (operation, object) > #sizeMismatch (objects) > #subclassResponsibility ** (message, receiver) > #notYetImplemented ** (message, receiver) > #cannotInstanciate ** (class) > #readOnlyObject ** (object) > OutOfFreeSpace ** <handlers?> > #invalidArgument ** (message, receiver, argument) > #notIndexable ** (object) > #noKeyedAccess ** (object) > #nonIntegerIndex ** (receiver, index) > #subscriptOutOfBounds ** (receiver, index, from, to) > NotFoundException ** (receiver, object) > #keyNotFound ** > #valueNotFound ** > #elementNotFound ** > StreamException (stream) > #positionError ** (index, from, to) > EndOfStream ** > #beginOfStream ** > > Notification > Admonition > LowMemory ** <this should be a notification not an error>

April 14, 2011

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

by Miguel CobÃ¡

El jue, 14-04-2011 a las 20:13 +0200, StÃ©phane Ducasse escribiÃ³: > Dale > > so it means that I write what? > > [] on: NumericError do: [:ex | ] > > how do I access the rangeError? [] on: NumericError do: [ :ex | ex reasonCode "This gets you #rangeError or any other symbol to detail the exception" ] Cheers -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

April 14, 2011

Re: [Pharo-project] Class Builder for Pharo, was Re: Improving Pharo's Exception Hierarchy

by Toon Verwaest

On 04/14/2011 08:09 PM, StÃ©phane Ducasse wrote: > On Apr 14, 2011, at 4:12 PM, Toon Verwaest wrote: > >> Be patient, be patient ;) >> >> I'm still very busy at the moment, but it'll get there. >> >> We'll probably have discuss if you want to generate slot and layout objects in the classbuilder, or if you want to replace the instanceVariables array with real layout objects that you keep around. We basically implemented everything around the layout objects and keep this data in all classes; but you'll have to figure out if you want this in Pharo or not. Decide and let me know, I'd say ;) > you know the answer (we want slots). After this is more a question of > - is the code robust > - what are the migration plans > - do we schedule that for when > > Stef Well for robustness reasons I suggest to start the port with only layouts and 1 type of slot object (the standard slot object). This slot object will in the first phase not influence compilation at all. We can also (in the first phase) keep the class format exactly the same as it was before, to not interfere with existing tools and code. This makes the layouts only metadata that is used by the class builder and the interface between the compiler and classes. The inspector can easily be rewritten to also use the slot metaobjects. If we do it in that format, I can tell you that layouts are stable and so is the migration. I can remove the decompilation/recompilation based on Opal for fast method rewriting for now, if you want to avoid too many dependencies at first and test the whole class builder independent of how methods are updated. This is basically just 1 line of code that needs to be changed so I can easily disable that ... If you give me an exact plan and an image into which I can bootstrap my classbuilder, I can do this first step by myself. Someone with more knowledge of the whole ecosystem could then help me to smooth out the problems. The only thing that isn't working yet atm is the class globals (the class variables), but that isn't really hard; it just needs to be done :) I really didn't care about that part, which is why it isn't there yet. Obviously my suggestion means that you won't have slots yet in the beginning, but I think that's the safest bet for now. The classbuilder works and doesn't introduce new concepts yet. It just cleans up existing code. cheers, Toon

April 14, 2011

Re: [Pharo-project] About float: new chapter looking for reader and contributors

by StÃ©phane Ducasse

On Apr 14, 2011, at 11:31 AM, Nicolas Cellier wrote: > I created a git account last night but must install latex on my mac. you can also just write and I will latex it. There is no problem. > I don't have your rythm :) :) But you are doing a lot of things too. Sometimes I have the impression that I could be more focused and it would be better but the system does not give me this chance. Stef

April 14, 2011

Re: [Pharo-project] isHealthy

by StÃ©phane Ducasse

Ok in fact I should have check do: first and I will change thses users of do: to replace with doValues: because I was following a wrong road because of it. Stef >>> >>> dict array == nil >>> should not happen, but >>> (dict array at: someindex ) == nil >>> is quite normal. >> I do not know I have a do: loop and some elements are nil and break the loop. >> >> Stef > > do: iterates the values in the Dictionary, and yes, it's perfectly valid to have a pair someKey -> nil in the dictionary. > Why you have it (ie who put it there), and if it should be valid in your case, you'd have to figure out :) > > Cheers, > Henry >

April 14, 2011

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

by StÃ©phane Ducasse

Dale so it means that I write what? [] on: NumericError do: [:ex | ] how do I access the rangeError? >> > > Using Sven's hierachy as a starting point and taking some cues from the GemStone exception hierarchy, I would suggest the following (names atarting with # are reasonCodes in the namespace of the parent exception class, instead of a unique class): > > Exception (messageText reasonCode) > Abort > Error > NumericError > #floatingPointException > #rangeError > #naNError > ZeroDivide (dividend) > FileStreamException (fileName) > #fileDoesNotExistException > #fileExistsException (fileClass) > #cannotDeleteFileException > #fileWriteError > #fileReadError ** > #fileClosedException ** > #cannotAccessFileException ** > #readonlyFileException ** > MessageNotUnderstood (message, receiver) > #nonBooleanReceiver (object) > OutOfMemory < handlers?> > ControlInterrupt > Halt > AssertionFailure > BreakPoint > CompileError > SyntaxError ** !exists! (input, position) > #numberFormatException ** > #headlessError ** > TimedOut ** (object, operation, timeout) > VerificationException > IllegalOperation ** (operation, object) > #sizeMismatch (objects) > #subclassResponsibility ** (message, receiver) > #notYetImplemented ** (message, receiver) > #cannotInstanciate ** (class) > #readOnlyObject ** (object) > OutOfFreeSpace ** <handlers?> > #invalidArgument ** (message, receiver, argument) > #notIndexable ** (object) > #noKeyedAccess ** (object) > #nonIntegerIndex ** (receiver, index) > #subscriptOutOfBounds ** (receiver, index, from, to) > NotFoundException ** (receiver, object) > #keyNotFound ** > #valueNotFound ** > #elementNotFound ** > StreamException (stream) > #positionError ** (index, from, to) > EndOfStream ** > #beginOfStream ** > > Notification > Admonition > LowMemory ** <this should be a notification not an error> >

April 14, 2011

Re: [Pharo-project] Class Builder for Pharo, was Re: Improving Pharo's Exception Hierarchy

by StÃ©phane Ducasse

On Apr 14, 2011, at 4:12 PM, Toon Verwaest wrote: > Be patient, be patient ;) > > I'm still very busy at the moment, but it'll get there. > > We'll probably have discuss if you want to generate slot and layout objects in the classbuilder, or if you want to replace the instanceVariables array with real layout objects that you keep around. We basically implemented everything around the layout objects and keep this data in all classes; but you'll have to figure out if you want this in Pharo or not. Decide and let me know, I'd say ;) you know the answer (we want slots). After this is more a question of - is the code robust - what are the migration plans - do we schedule that for when Stef

April 14, 2011