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 asqueaker@gmail.com 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.
squeak-dev@lists.squeakfoundation.org