Dolphin 98 exception handling problem

We're porting our new unit testing framework to Dolphin 98, and we've
encountered a problem. Try evaluating the following two expressions:

"answers 'dnu occurred', as expected"
[1 dnu] on: MessageNotUnderstood do: [:signal | signal exit: 'dnu occurred']

"answers 'completed', but expected to answer 'dnu occurred'"
[1 dnu . 'completed'] on: MessageNotUnderstood do: [:signal | signal exit:
'dnu occurred']

Is the second result a bug, or am I misunderstanding something about Dolphin
98 exception handling?

Regards,

Peter van Rooijen

Peter

You wrote in message news:96h2lv$t0q$[hidden email]...
> We're porting our new unit testing framework to Dolphin 98, and we've
> encountered a problem. Try evaluating the following two expressions:
>
> "answers 'dnu occurred', as expected"
> [1 dnu] on: MessageNotUnderstood do: [:signal | signal exit: 'dnu
occurred']
>
> "answers 'completed', but expected to answer 'dnu occurred'"
> [1 dnu . 'completed'] on: MessageNotUnderstood do: [:signal | signal exit:
> 'dnu occurred']
>
> Is the second result a bug, or am I misunderstanding something about
Dolphin
> 98 exception handling?

The latter: You are misunderstanding the behaviour of #exit:. The comment in
Exception>>exit: says:

"Answer the argument as the value of the handler block, as if it were the
value of the last expression in the try block. For non-resumable exceptions,
this is equivalent to #return:, for resumable #resume:. This is no longer
part of the ANSI standard set of handler responses."

MessageNotUnderstood is a resumable exception, and therefore #exit: will
resume execution in the guarded block.

FWIW the behaviour is exactly the same in D3 and D4. I should also draw your
attention to the fact that #exit: is non-standard. It was in the earlier
drafts of the ANSI standard (hence its presence in Dolphin), but was removed
(the confusion as to its behaviour illustrates why I think). The behaviour
of #exit: in all versions of Dolphin does follow that specified in those
earlier drafts (i.e. to do different things depending on whether the
exception is resumable or not). To get the behaviour you want use the
standard handler response #return:, or simply drop off the end of the
handler block which is effectively the same thing.

Regards

Blair

> > "answers 'dnu occurred', as expected"
> > [1 dnu] on: MessageNotUnderstood do: [:signal | signal exit: 'dnu
> occurred']
> >
> > "answers 'completed', but expected to answer 'dnu occurred'"
> > [1 dnu . 'completed'] on: MessageNotUnderstood do: [:signal | signal
exit:
> > 'dnu occurred']
> >
> > Is the second result a bug, or am I misunderstanding something about
> Dolphin
> > 98 exception handling?
>
>
> The latter: You are misunderstanding the behaviour of #exit:. The comment
in
> Exception>>exit: says:
>
> "Answer the argument as the value of the handler block, as if it were the
> value of the last expression in the try block. For non-resumable
exceptions,
> this is equivalent to #return:, for resumable #resume:. This is no longer
> part of the ANSI standard set of handler responses."
>
> MessageNotUnderstood is a resumable exception, and therefore #exit: will
> resume execution in the guarded block.

I see. I was trying to get what #exitWith: does in VisualAge (it provides
the return value of #on:do:), and it seems not to be #exit: .

> FWIW the behaviour is exactly the same in D3 and D4. I should also draw
your
> attention to the fact that #exit: is non-standard. It was in the earlier
> drafts of the ANSI standard (hence its presence in Dolphin), but was
removed
> (the confusion as to its behaviour illustrates why I think). The behaviour
> of #exit: in all versions of Dolphin does follow that specified in those
> earlier drafts (i.e. to do different things depending on whether the
> exception is resumable or not). To get the behaviour you want use the
> standard handler response #return:

OK, so return is the equivalent of #exitWith: that I'm looking for.

>, or simply drop off the end of the
> handler block which is effectively the same thing.

Is it also the same thing if I have two nested handlers?

[[] on: E1 do: []] on: E2 do: []

In any case, thanks very much. The port should be available soon. This
particular problem was already easy to work around, but I'll see if I can
use your suggestion (which would allow me to use clean blocks). Then on to
widget attachments.

Best regards,

Peter van Rooijen

> Regards
>
> Blair

Peter

You wrote in message news:96ha7j$fl7$[hidden email]...

> I see. I was trying to get what #exitWith: does in VisualAge (it provides
> the return value of #on:do:), and it seems not to be #exit: .
> ...
> OK, so return is the equivalent of #exitWith: that I'm looking for.

Yes, #return: is the ANSI equivalent of #exitWith: in VisualAge (from what
you say). Actually I'm surprised that VA doesn't implement #return: now.

>
> >, or simply drop off the end of the
> > handler block which is effectively the same thing.
>
> Is it also the same thing if I have two nested handlers?
>
> [[] on: E1 do: []] on: E2 do: []

Yes, #return: and dropping off the end are always the same thing because
thats what the ANSI spec says (at least by my reading), and in Dolphin if an
exception handler block returns then the code which invokes it calls
#return: anyway. #return:, or dropping off the end of the handler block,
always causes execution to resume at a point immediately after the handler
block in the source. In your nested case this would mean still within the
context of the trap established for E2, not after the handler for E2.

As an aside, I think nested handlers are almost always not precisely what
one wants in these cases because they aren't at the same level. Are you
merely nesting the handlers because of a lack of #on:do:on:do:[etc]. Nesting
is not quite the same thing as being able to handle multiple different types
of exception separately at the same level. Do you want the handler for E1 to
be evaluated within an exception environment that will trap E2 (i.e.
nesting), or are you actually trying to express this instead:

[]
    on: E1 do: [:e |]
    on: E2 do: [:e |].

This would behave quite differently if the handler for E1 raised E2, as the
handler for E2 has gone out of scope by the time it is evaluated (unlike the
nested case).

I argued for registering multiple exception handlers for different
exceptions against the same guarded block on the ANSI committee, but it
wasn't adopted into the standard unfortunately. Nevertheless Dolphin
supports them, and it is fairly trivial to enhance an ANSI implementation to
support this (if it is implemented in Smalltalk rather than in the VM that
is).

Regards

Blair

"Blair McGlashan" <[hidden email]> wrote in message
news:96ho06$l1qki$[hidden email]...
> Peter
>
> You wrote in message news:96ha7j$fl7$[hidden email]...
>
> > I see. I was trying to get what #exitWith: does in VisualAge (it
provides
> > the return value of #on:do:), and it seems not to be #exit: .
> > ...
> > OK, so return is the equivalent of #exitWith: that I'm looking for.
>
> Yes, #return: is the ANSI equivalent of #exitWith: in VisualAge (from what
> you say). Actually I'm surprised that VA doesn't implement #return: now.

VisualAge actually does implement #return: as part of the ANSI-API (I just
looked it up and it does self exitWith: ;-)). It's just that I'm familiar
with the 'old' protocol.

[snip]

> As an aside, I think nested handlers are almost always not precisely what
> one wants in these cases because they aren't at the same level. Are you
> merely nesting the handlers because of a lack of #on:do:on:do:[etc].

Yes, you are right, and, yes that's why. This is in code that carries an
intention of being cross-platform. I'm going to step away from that
approach, though, and create the cross-platformness in another way, that
doesn't suffer the drawbacks.

> Nesting
> is not quite the same thing as being able to handle multiple different
types
> of exception separately at the same level. Do you want the handler for E1
to
> be evaluated within an exception environment that will trap E2 (i.e.
> nesting), or are you actually trying to express this instead:
>
> []
>     on: E1 do: [:e |]
>     on: E2 do: [:e |].
>
> This would behave quite differently if the handler for E1 raised E2, as
the
> handler for E2 has gone out of scope by the time it is evaluated (unlike
the
> nested case).

Absolutely. The nested structure makes the second exception handler guard
too much. I'm going to rewrite this so it is completely portable and can use
the multiple handler functionality if it is available on the platform.

> I argued for registering multiple exception handlers for different
> exceptions against the same guarded block on the ANSI committee, but it
> wasn't adopted into the standard unfortunately. Nevertheless Dolphin
> supports them, and it is fairly trivial to enhance an ANSI implementation
to
> support this (if it is implemented in Smalltalk rather than in the VM that
> is).

Thank you very much for your insightful remarks.

Regards,

Peter van Rooijen

Friends,

We've uploaded a Dolphin 98 version of our new unit testing framework and
tool to www.wikiweb.com/~UnitTesting . We're not telling you this to promote
the software, but to ask for your feedback on the stupid mistakes we have
certainly made as Dolphin inexperionados. With your help we will hopefully
be able to release pretty reasonable code in a few weeks.

We know we don't know enough about:
- how to do widget attachments
- how do set the window background color to use the user's default
- how to get mnemonics on pop-up menus
- how to use CommandQuery
- how to add this tool to the Tools menu
- how to integrate with native browsers
- what (conventional) names to use for command methods
- how to write one version that runs on 3.0 and 4.0 as well

Hope you will tell us what else we need to know.

Regards,

Peter van Rooijen
Job ter Haar

Peter,

> We know we don't know enough about:
> - how to do widget attachments

I'm not sure what you mean by this.


> - how do set the window background color to use the user's default

I vaguely recall something about using indexed colors for such purposes,
but, obviously, I'm not the person to ask about this.  Somehow, I suspect
the Dolphin community would welcome the framework regardless of the
background color, especially since it's easy to change using the VC.


> - how to get mnemonics on pop-up menus

Setting an accelerator will probably do what you want.  The way I know to
set them is to use the menu editor, select a command, go to the accelerator
field and type the character (holding down alt or control if appropriate)
and it "just happens".


> - how to use CommandQuery

Ian has written excellent descriptions about this, and just posted something
not long ago.  The short version is that Dolphin wants you to invalidate a
command, not a button or menu item.  That way, one
enable/disable/check/uncheck operation affects all UI elements tied to the
command.

You can download the newsgroup archive from Ian's web site

  http://www.iandb.org.uk/

and use either his archive browser, or DSDN, which Ian and I wrote together
and sits on my web site

   http://needle.anest.ufl.edu/anest4/bills/

A few keyword searches against the archive will make a believer out of you
:)  The Dolphin Wiki is a good resource too.


> - how to add this tool to the Tools menu

See almost any of Ian's goodies, or a few of mine (Migrate comes to mind).
It's as simple as writing a few class methods in the shell class.


> - how to integrate with native browsers

Aside from the 3rd party integration (putting it on the tools menu), what do
you want to do?


> - what (conventional) names to use for command methods

The most basic thing is to categorize them as commands, you can call them
pretty much anything.


> - how to write one version that runs on 3.0 and 4.0 as well

My first advice would be to write it for 3 and then test on 4; post here if
you get stuck.  Others might have more to say.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Fellow Smalltalkers,

Dolphin 98 Summer 99.

I'm sorry to announce that two things went wrong with our upload:

- We didn't include the newest user interface library. We were sure we had
saved that package and included it, but the time stamp says differently.
Does anyone know of packages sometimes not saving in Dolphin98? I hope this
was just our mistake, and that the system works OK, but I have to ask. Not a
big problem, though, you'll just not get the most up to date user interface.
Anyway, easily fixed.

- There is a problem with the dependencies. I don't know how to fix this.
When we load the top level package, it automatically loads several packages,
but it has the order wrong. We changed the dependency structure at some
point (we inserted a package at some point, and may have made other
changes). We now get methods that didn't compile because a class they
reference is undeclared.

This is what the Transcript says:

Loading in Cssu Unit Testing Framework package from C:\Program Files\Dolphin
Smalltalk 98\Packages\Cssu\Cssu Unit Testing Framework.pac
Error: CssuTestCase>>should:raise: at line 2: undeclared
'CssuSmalltalkDialect'
Error: CssuTestCase>>shouldnt:raise: at line 2: undeclared
'CssuSmalltalkDialect'
Error: CssuTestCase>>signalFailure: at line 2: undeclared
'CssuSmalltalkDialect'
Loading in Cssu Environment Abstraction Facility package from C:\Program
Files\Dolphin Smalltalk 98\Packages\Cssu\Cssu Environment Abstraction
Facility.pac
Loading in Cssu Dialect Abstraction Facility package from C:\Program
Files\Dolphin Smalltalk 98\Packages\Cssu\Cssu Dialect Abstraction
Facility.pac
Loading in Cssu Tool Library package from C:\Program Files\Dolphin Smalltalk
98\Packages\Cssu\Cssu Tool Library.pac
Loading in Cssu User Interface Library package from C:\Program Files\Dolphin
Smalltalk 98\Packages\Cssu\Cssu User Interface Library.pac

It seems it loads the unit testing framework before loading the dialect
abstraction facility which defines the class it complains about. I just
saved these packages to a new directory from an image in which everything
works fine, and I'm loading into a new image. Funny thing is that the image
that works correctly *does* show the references that cause the prerequisite
relationship. So it seems it detects them alright, but it won't save them
into the package.

If I load the packages by hand in a correct order, they don't show the same
problem. So, now I have a distribution that you have to load by hand. It's
not pretty but it will have to do until I learn how to update the
dependencies. Here's the order for doing it by hand:

Loading in Cssu Dialect Abstraction Facility package from C:\Program
Files\Dolphin Smalltalk 98\Packages\Cssu\Cssu Dialect Abstraction
Facility.pac
Loading in Cssu Unit Testing Framework package from C:\Program Files\Dolphin
Smalltalk 98\Packages\Cssu\Cssu Unit Testing Framework.pac
Loading in Cssu Environment Abstraction Facility package from C:\Program
Files\Dolphin Smalltalk 98\Packages\Cssu\Cssu Environment Abstraction
Facility.pac
Loading in Cssu Tool Library package from C:\Program Files\Dolphin Smalltalk
98\Packages\Cssu\Cssu Tool Library.pac
Loading in Cssu User Interface Library package from C:\Program Files\Dolphin
Smalltalk 98\Packages\Cssu\Cssu User Interface Library.pac
Loading in Cssu Test Case Library package from C:\Program Files\Dolphin
Smalltalk 98\Packages\Cssu\Cssu Test Case Library.pac

I'll upload this to www.wikiweb.com/~UnitTesting as soon as it is back up
again. Sorry for the inconvenience. Hope you can help me out with the
dependencies.

Regards,

Peter van Rooijen



"Peter van Rooijen" <[hidden email]> wrote in message
news:96md9l$3l8$[hidden email]...
> Friends,
>
> We've uploaded a Dolphin 98 version of our new unit testing framework and
> tool to www.wikiweb.com/~UnitTesting . We're not telling you this to
promote

> I'll upload this to www.wikiweb.com/~UnitTesting as soon as it is back up
> again.

The new file has now been uploaded to the wiki.

Regards,

Peter van Rooijen