able to resume non-resumable Errors in the Debugger

Error signal.  3   "Error, but then press Proceed ----> 3"

[Error signal] on: Error do: [ : err | err resume: 3 ]
"IllegalResumeAttempt, but then press Proceed -----> 3"

This is not a regression from 4.5, but something to be aware of when
using the debugger, because Error signalers assume the code that
follows will not be run.

Hi Chris,

    it has ever been so and is very useful.  Personally I would prefer the proceed ability if exceptions to be changeable depending in circumstance.  eg initialise a canPeoceed inst car to the class default but allow knowledgeable clients to alter the status quo.  Often exception designers err on making errors not proceedable.  For example accessing a directory's contents.  If implementing find (1) it's useful to be able to proceed with an empty collection, to skip directories one doesn't have the permissions to read.

Eliot (phone)

On Jun 24, 2015, at 1:02 PM, Chris Muller <[hidden email]> wrote:

> Error signal.  3   "Error, but then press Proceed ----> 3"
>
> [Error signal] on: Error do: [ : err | err resume: 3 ]
> "IllegalResumeAttempt, but then press Proceed -----> 3"
>
> This is not a regression from 4.5, but something to be aware of when
> using the debugger, because Error signalers assume the code that
> follows will not be run.
>

>     it has ever been so and is very useful.  Personally I would prefer the proceed ability if exceptions to be changeable depending in circumstance.

It already is.  Just implement isResumable  ^true temporarily (and in
the meantime reconsider the design of the app's use of a non-resumable
exception for that case).

> eg initialise a canPeoceed inst car to the class default but allow knowledgeable clients to alter the status quo.  Often exception designers err on making errors not proceedable.  For example accessing a directory's contents.  If implementing find (1) it's useful to be able to proceed with an empty collection, to skip directories one doesn't have the permissions to read.

Yes, I know what you are saying, but I'm talking about non-resumable
Errors.  There are cases when the code following the signal absolutely
should not run; e.g. if the user mistakenly clicked Proceed and there
were "repercussions" for resuming the code there.

Actually, this issue is not serious for the release like the step over
Warning and the step through image lockup issue are.  If we cannot get
those fixed in another week, we may wish to rollback the offending
change(s) so we can release, re-open development for trunk, and mount
another attack on those changes.