Smalltalk › Pharo › Pharo Smalltalk Developers

Improving Pharo's Exception Hierarchy

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

54 messages Options

123

Hernan Wilkinson-3

Re: Improving Pharo's Exception Hierarchy

On Thu, Apr 14, 2011 at 1:38 PM, Alexandre Bergel <[hidden email]> wrote:

> I think you said it right here: "having classes for all _relevant_ concepts actually pays off"...

I do not quite agree on this. Responsibility should be the driver, not the concepts.

that is a good point

Alexandre

> Related to exceptions, my question is: what are all the different concepts you have? for example, not finding a Key or not finding a Value are really different concepts? or is it the same (not finding something) that depending on the context (finding a value or a key) is what looks like they are different? if so, then there is only one concept (i.e. not finding an object), if it is a key or a value is accidental, contextual to what you are looking for.
> So, I completely agree when you say "having classes for all relevant concepts"... I think we do not agree on what are the relevant concepts when we talk about exceptions...
>
>
> Toon
>
>
> On 04/14/2011 01:00 AM, Dale Henrichs wrote:
> 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 ...
>
>
>
>
>
>
>
> --
> Hernán Wilkinson
> Agile Software Development, Teaching & Coaching
> Mobile: +54 - 911 - 4470 - 7207
> email: [hidden email]
> site: http://www.10Pines.com
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 911 - 4470 - 7207
email: [hidden email]
site: http://www.10Pines.com

Stéphane Ducasse

Re: Class Builder for Pharo, was Re: Improving Pharo's Exception Hierarchy

In reply to this post by Toon Verwaest-2

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

Stéphane Ducasse

Re: Improving Pharo's Exception Hierarchy

In reply to this post by Dale Henrichs

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

Toon Verwaest-2

Re: Class Builder for Pharo, was Re: Improving Pharo's Exception Hierarchy

In reply to this post by Stéphane Ducasse

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

Miguel Cobá

Re: Improving Pharo's Exception Hierarchy

In reply to this post by Stéphane Ducasse

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

Sven Van Caekenberghe

Re: Improving Pharo's Exception Hierarchy

In reply to this post by Dale Henrichs

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>

Dale Henrichs

Re: Improving Pharo's Exception Hierarchy

In reply to this post by Stéphane Ducasse

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

Dale Henrichs

Re: Improving Pharo's Exception Hierarchy

In reply to this post by Sven Van Caekenberghe

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

Henrik Sperre Johansen

Re: Improving Pharo's Exception Hierarchy

In reply to this post by Dale Henrichs

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

csrabak

Re: Improving Pharo's Exception Hierarchy

In reply to this post by Dale Henrichs

Not willing to rattle cages, reading this particular set of postings I wonder if its my sole feeling or this kind of code 'leads to' naturally to a screaming need for a CaseOf construct?

In the snippet below submitted by Dale if we have some other [expected] numeric errors (a.k.a. 'reasons') you would end up with a very hairy entanglement of ifTrue:[]ifFalse:[], wouldn't you?

my 0.01999.....

--
Cesar Rabak

Em 14/04/2011 15:52, Dale Henrichs < [hidden email] > escreveu:
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 **
>> #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 **
>>
>
>

Dale Henrichs

Re: Improving Pharo's Exception Hierarchy

In reply to this post by Henrik Sperre Johansen

On 04/14/2011 12:04 PM, Henrik Sperre Johansen wrote:

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

At GemStone we decided not to use tag (we had several cats to skin), but
tag could certainly be used...

Dale

Dale Henrichs

Re: Improving Pharo's Exception Hierarchy

In reply to this post by csrabak

Cesar,

Good point.

Exception handling code even when using simple class-based exceptions
and exception sets does indeed devolve into CaseOf constructs. Using
classes, the following code is still common:

[
(RangeError new) signal: 'access out of bounds'
]
on: Error
do: [:ex |
(ex isKindOf: RangeError)
ifTrue: [ "do your thang" ]
ifFalse: [ ex pass ]].

and using ExceptionSets doesn't lead to anything better. At GemStone we
_have_ added an extention that looks something like the following to get
away from explicit CaseOf code:

[
(NumericError new)
reason: #rangeError;
signal: 'access out of bounds'
]
onExceptions: NaNError, RangeError
do:
{
[:naNError | "do something with NANError"].
[:rangeError | "o something with RangeError"].
}.

but it's just a different form of CaseOf...I don't think the use of
reasonCodes is the cause...

To get around this, I guess you'd have to start extending various
Exception classes with "handler-specific" methods that would allow you
to double dispatch your way out of the CaseOf construct...

Dale

n 04/14/2011 12:38 PM, [hidden email] wrote:

> Not willing to rattle cages, reading this particular set of postings
> I wonder if its my sole feeling or this kind of code 'leads to'
> naturally to a screaming need for a CaseOf construct?
>
> In the snippet below submitted by Dale if we have some other
> [expected] numeric errors (a.k.a. 'reasons') you would end up with a
> very hairy entanglement of ifTrue:[]ifFalse:[], wouldn't you?
>
> my 0.01999.....
>
> -- Cesar Rabak
>
>
> Em 14/04/2011 15:52, Dale Henrichs< [hidden email]> escreveu:
> 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 ** #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 **
>>>
>>
>>
>
>
>
>

Stéphane Ducasse

Re: Class Builder for Pharo, was Re: Improving Pharo's Exception Hierarchy

In reply to this post by Toon Verwaest-2

sounds good.
We should sycn with marcus.
Yes having first a cleaning classbuilder is a good step.

Stef

On Apr 14, 2011, at 8:18 PM, Toon Verwaest wrote:

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

Stéphane Ducasse

Re: Improving Pharo's Exception Hierarchy

In reply to this post by Miguel Cobá

ok tx

On Apr 14, 2011, at 8:27 PM, Miguel Cobá wrote:

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

123