Outlook jumbled my message completely. Here the examples again:

[self model merge] on: MCMergeResolutionRequest & [:request | request merger conflicts notEmpty] do: [:request | request resume: true].

[client unusedBytecode] on: MessageNotUnderstood & [:ex | ex receiver == client] & [:ex | ex message selector == #unusedBytecode] do: [self error: 'unusedBytecode'].

references := [self resolvePackageSpecReferences: packageSpec gofer: gofer] on: [self class retryPackageResolution] & (Error , GoferRepositoryError) do: [:ex | retryCount >= 2 ifFalse: [ ex return: #() ] on: [self class retryPackageResolution] & GoferRepositoryError. Transcript showln: 'gofer repository error: '; show: ex description printString; show: '...ignoring'. (repositoryError := ex) resume: #()].

sz := 1024*1024*1024*1024. self should: [Array new: sz] raise: OutOfMemory, (Error & [:ex | ex messageText includesSubstring: 'basicNew: with invalid argument']).

Hi Christoph,

you are proposing an interface to avoid having to deal with Exception >> #pass and #resume:. I like #on:when:do:, maybe renamed to: #on:satisfying:do:. I do not like your & syntax because it would mix Exception, ExceptionSet, and BlockClosure -- which may be hard to understand and debug.

Bset, Marcel Am 09.10.2020 03:15:43 schrieb Chris Muller asqueaker@gmail.com: Hi Christoph,

Are these equivalent --

On Thu, Jan 2, 2020 at 7:58 PM Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de [mailto:Christoph.Thiede@student.hpi.uni-potsdam.de]> wrote:

Outlook jumbled my message completely. Here the examples again:

[self model merge]         on: MCMergeResolutionRequest                 & [:request | request merger conflicts notEmpty]         do: [:request | request resume: true].

equal to:

[self model merge]         on: MCMergeResolutionRequest         do:             [:request | request merger conflicts notEmpty                 ifTrue: [request resume: true]                 ifFalse: [request pass] ]

?

[client unusedBytecode]         on: MessageNotUnderstood                 & [:ex | ex receiver == client]                 & [:ex | ex message selector == #unusedBytecode]         do: [self error: 'unusedBytecode'].

equal to

[client unusedBytecode]          on: MessageNotUnderstood          do:                [:ex | (ex receiver == client and: [ ex message selector == #unusedBytecode ])                       ifTrue: [ self error: 'unusedBytecode' ]                       ifFalse: [ ex pass ] ]

?

Not sure if I fully understood it, but is it just a reformat of the syntax?  Or something more empowering?

references := [self resolvePackageSpecReferences: packageSpec gofer: gofer]         on: [self class retryPackageResolution] & (Error , GoferRepositoryError)         do: [:ex | retryCount >= 2 ifFalse: [                 ex return: #() ]         on: [self class retryPackageResolution] & GoferRepositoryError.                 Transcript showln: 'gofer repository error: '; show: ex description printString; show: '...ignoring'.                 (repositoryError := ex) resume: #()].

(wait, is that, #on:do:on: ?  I'm confused on this one...)

- Chris

sz := 1024*1024*1024*1024. self         should: [Array new: sz]         raise: OutOfMemory, (Error & [:ex | ex messageText includesSubstring: 'basicNew: with invalid argument']).

See Kernel-ct.1292/2 for the next attempt. :-)

Hm, no, SqueakSource has renamed it into Kernel-ct.1303. Eliot, didn't you mention that one can use slashes to create branches in Monticello?

Best, Christoph

________________________________ Von: Thiede, Christoph Gesendet: Freitag, 9. Oktober 2020 16:41:09 An: Chris Muller; squeak-dev Betreff: AW: [squeak-dev] Exception patterns (The Inbox: Kernel-ct.1292.mcz)

Hi Marcel, Hi Chris,

thanks for your feedback. I see your point of complexity, still, I think BlockClosure #& etc. could be a nice concept, but it would rather belong in an own repository (such as Xtreams, for example).

See Kernel-ct.1292/2 for the next attempt. :-)

http://www.hpi.de/

@Chris: You're right with your interpretation, I'm aiming to get rid of this low-level #pass sends and all the condition logic inside handlerActions.

(wait, is that, #on:do:on: ? I'm confused on this one...)

Oops, this should have been #on:do:on:do: instead. But I fear this would be over-complicated anyway ...

Best, Christoph ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Freitag, 9. Oktober 2020 08:57:05 An: Chris Muller; squeak-dev Betreff: Re: [squeak-dev] Exception patterns (The Inbox: Kernel-ct.1292.mcz)

Hi Christoph,

you are proposing an interface to avoid having to deal with Exception >> #pass and #resume:. I like #on:when:do:, maybe renamed to: #on:satisfying:do:. I do not like your & syntax because it would mix Exception, ExceptionSet, and BlockClosure -- which may be hard to understand and debug.

Bset, Marcel

Am 09.10.2020 03:15:43 schrieb Chris Muller asqueaker@gmail.com:

Hi Christoph,

Are these equivalent --

On Thu, Jan 2, 2020 at 7:58 PM Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.demailto:Christoph.Thiede@student.hpi.uni-potsdam.de> wrote: Outlook jumbled my message completely. Here the examples again:

[self model merge] on: MCMergeResolutionRequest & [:request | request merger conflicts notEmpty] do: [:request | request resume: true].

equal to:

[self model merge] on: MCMergeResolutionRequest do: [:request | request merger conflicts notEmpty ifTrue: [request resume: true] ifFalse: [request pass] ]

?

[client unusedBytecode] on: MessageNotUnderstood & [:ex | ex receiver == client] & [:ex | ex message selector == #unusedBytecode] do: [self error: 'unusedBytecode'].

equal to

[client unusedBytecode] on: MessageNotUnderstood do: [:ex | (ex receiver == client and: [ ex message selector == #unusedBytecode ]) ifTrue: [ self error: 'unusedBytecode' ] ifFalse: [ ex pass ] ]

?

Not sure if I fully understood it, but is it just a reformat of the syntax? Or something more empowering?

references := [self resolvePackageSpecReferences: packageSpec gofer: gofer] on: [self class retryPackageResolution] & (Error , GoferRepositoryError) do: [:ex | retryCount >= 2 ifFalse: [ ex return: #() ] on: [self class retryPackageResolution] & GoferRepositoryError. Transcript showln: 'gofer repository error: '; show: ex description printString; show: '...ignoring'. (repositoryError := ex) resume: #()].

(wait, is that, #on:do:on: ? I'm confused on this one...)

- Chris

sz := 1024*1024*1024*1024. self should: [Array new: sz] raise: OutOfMemory, (Error & [:ex | ex messageText includesSubstring: 'basicNew: with invalid argument']).

Hm ... I just tried to upload Kernel.ct.1362-ct.2 (branch name: "ct.1362"), but it was uploaded as Kernel-ct.1362 ... The next time I will try it without a dot in the branch name. :-)

-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html

On Sat, Nov 07, 2020 at 03:58:58PM +0100, Jakob Reschke wrote:

Am Sa., 7. Nov. 2020 um 13:51 Uhr schrieb Christoph Thiede christoph.thiede@student.hpi.uni-potsdam.de:

...

Hm ... I just tried to upload Kernel.ct.1362-ct.2 (branch name: "ct.1362"), but it was uploaded as Kernel-ct.1362 ... The next time I will try it without a dot in the branch name. :-)

So yes Monticello can produce branches, but it seems all but obvious how to use them (right).

For a memory aid, look at the packages 'Compiler' and 'Compiler.spur' in trunk. The entries in Compiler.spur are of the form Compiler.spur-eem.287, so the naming convention when saving a branch version is to add '.spur' the the package name 'Compiler' to get 'Compiler.spur'. The '-eem' and '.287' are author and file version number. The actual branching is seen only in the version history of any of these version entries, and it may not match the history implied by the names.

For the example that Christoph provides above, suppose that Christoph was working on the Kernel package, and he wants to save some inbox versions branched from Kernel-eem.1361. In this example, the changes are going to be related to Context>>runSimulated, so he might want to identify these as a feature branch called 'runSimulated'. in that case, he might enter the name 'Kernel.runSimulated-ct.1362' rather than 'Kernel-ct.1362' when saving 1362 to the inbox. Then, when saving the next version 1363, it would be saved as 'Kernel.runSimulated-ct.1363'.

This system is far from perfect, but it does work. Do not expect it to be as elegant or efficient as git, it is not.

As Jakob says, the above is not obvious and that's why I mention it here.

Dave

#on:when:do: isn't a terrible idea but be aware of the all-too-common problem of getting too clever. Remember, debugging is at least twice as hard as writing code and so if you make your code as clever as you can...

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IG: Insert Garbage

Hi all,

I'd like to push this discussion again because I still do think that an #on:when:do: mechanism or whatever you'd like to call it can be useful in several situations.

One of my favorite usages is this:

[self downloadFile: aFile on: HttpError "this is from one of my packages" when: [:ex | ex statusCode = 403] do: [self inform: 'Forbidden!'].

Do I see it right that we only need to find a better name for this or am I the only one who would like to something like this in the Trunk? And would anyone be so kind and leave some feedback on my other proposal for exception conditions? :-)

[self downloadFile: aFile on: HttpError & [:ex | ex statusCode = 403] do: [self inform: 'Forbidden!'].

Best, Christoph

-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html

Note Squeak's object events: #when:send:to:. There, "when" requires an event object as a look-up key in the event map. Usually a Symbol.

Best, Marcel Am 03.01.2020 07:43:42 schrieb Jakob Reschke forums.jakob@resfarm.de: Note that VA Smalltalk has a legacy approach to exceptions that precedes the ANSI standard. It uses #when:do: in place of #on:do:. (Nowadays it also supports #on:do: but not for old-style exceptions in applications.) Might not a blocker for the proposed nomenclature, but you should at least be aware of it.

<commits@source.squeak.org [mailto:commits@source.squeak.org]> schrieb am Fr., 3. Jan. 2020, 02:21:

A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-ct.1292.mcz [http://source.squeak.org/inbox/Kernel-ct.1292.mcz]

==================== Summary ====================

Name: Kernel-ct.1292 Author: ct Time: 3 January 2020, 2:21:26.297116 am UUID: 95936a10-85a4-734e-a10b-0f87290b70f9 Ancestors: Kernel-nice.1291

Proposal: Implement conditional exception handling on blocks. The nomenclature is inspired from usual practice in .NET languages.

For an impression of possible users, have a look at:

self systemNavigation                 browseMessageList: ((self systemNavigation allCallsOn: #on:do: and: #pass) intersection: (#(ifTrue: ifFalse: ifTrue:ifFalse: ifFalse:ifTrue:) gather: [:sel | self systemNavigation allCallsOn: sel]))                 name: 'Potential users of #on:when:do:'

=============== Diff against Kernel-nice.1291 ===============

Item was added: + ----- Method: BlockClosure>>on:when:do: (in category 'exceptions') ----- + on: exceptionOrExceptionSet when: aPredicate do: handlerAction + +       ^ self +               on: exceptionOrExceptionSet +               do: [:exception | +                       (aPredicate value: exception) +                               ifTrue: [handlerAction cull: exception] +                               ifFalse: [exception pass]]!

Item was added: + ----- Method: BlockClosure>>on:when:ensure: (in category 'exceptions') ----- + on: exceptionOrExceptionSet when: aPredicate ensure: aBlock + +       ^ self +               on: exceptionOrExceptionSet +               do: [:exception | +                       (aPredicate value: exception) +                               ifTrue: [aBlock value]. +                       exception pass]!