Exception>>#exit: causes image to freeze

Hello all,

I notice a minor bug in 5.1, the workaround is simple but anyway here it is:

The following code will block Dolphin 5.1 process with 100% CPU utilization.

| fileStream |
[fileStream := FileStream read: 'non-existing file'] on: Error do: [:ex | ex
exit: 'my result'].

This worked without problems on Dolphin 5.0.

Best regards,

David Gorisek

David

You wrote in message news:[hidden email]...
> Hello all,
>
> I notice a minor bug in 5.1, the workaround is simple but anyway here it
is:
>
> The following code will block Dolphin 5.1 process with 100% CPU
utilization.
>
> | fileStream |
> [fileStream := FileStream read: 'non-existing file'] on: Error do: [:ex |
ex
> exit: 'my result'].
>
> This worked without problems on Dolphin 5.0.

This isn't a bug, but a consequence of enhancement #1210 (see the release
notes). In summary FileExceptions resulting from failed file opens are now
resumable, and when resumed the file open is retried. Since the non-standard
Exception>>exit: message will resume a resumable error, and not exit from
the handler block, the expression above will loop infinitely. To be certain
of returning from the handler block use the ANSI standard #return: message.

Regards

Blair

Blair,

thanks for clarifying this. BTW: what is the difference between:

result := [FileStream read: 'something'] on: Error do: [:ex | ].

and:

result := [FileStream read: 'something'] on: Error do: [:ex | ex return:
nil].

Both seem to work the same way.

Best regards,

David


"Blair McGlashan" <blair@no spam object-arts.com> wrote in message
news:[hidden email]... |
> ex
> > exit: 'my result'].
> >
> > This worked without problems on Dolphin 5.0.
>
> This isn't a bug, but a consequence of enhancement #1210 (see the release
> notes). In summary FileExceptions resulting from failed file opens are now
> resumable, and when resumed the file open is retried. Since the
non-standard
> Exception>>exit: message will resume a resumable error, and not exit from
> the handler block, the expression above will loop infinitely. To be
certain
> of returning from the handler block use the ANSI standard #return:
message.
>
> Regards
>
> Blair
>
>

David

You wrote in message news:[hidden email]...
There is no difference. A comment at the end of
Exception>>_evaluateHandler:in: explains all:

    ...
    "If the user supplied exception handling block terminates by dropping
off its end,
    without specifying a particular action, then we default to continuing
execution
    immediately after the try block, even if the exception is resumable.
This change
    for compatibility with latest X3J20 proposal, Sept. 96, BSM."

    ^anExceptionHandler return: answer.

"answer" will be whatever the exception handler block evaluates to if it
doesn't explicitly invoke a handler response.

Regards

Blair