That works perfectly in the example code, thank you.
I'm surprised as I thought I'd tried it and I thought that 'error' sends 'halt'.
Putting a 'self halt' in the problem area doesn't bring up the debugger in my real code. I suspect now that the function in which I'm trying to put a breakpoint is not actually being called, and so I'll have to dig deeper to figure out where the error message I am seeing is coming from.
(Perhaps I'll see if I can find out where the error is being trapped, remove the trap, and hope to get a debugger in the locus of the problem.)
I appreciate the help. Clinton Blackmore
On Fri, Dec 10, 2010 at 6:55 PM, Bert Freudenberg bert@freudenbergs.dewrote:
On 10.12.2010, at 16:37, Clinton Blackmore wrote:
Greetings.
In one area of code, I need to set a break point and do some debugging. This code is called deeply within a block that is wrapped up so that the end user does not see errors that occur.
In very simplified form, it is like this:
[ self error: 'Throwing an error' ] ifError: [:err :rcvr | Transcript show: 'Trapped error']
When I 'do it', this example will always trap the error instead of breaking into the debugger (which, quit clearly, it is designed to do.)
While I shudder to think of how easily it could be abused, there is no way to break into a debugger anyway, is there (without finding and disabling the outer block that is sent ifError)? Perhaps a hypothetical self untrappableError or self bringUpTheDebuggerPlease?
To set a breakpoint do "self halt":
[ self halt. self error: 'Throwing an error' ] ifError: [:err :rcvr | Transcript show: 'Trapped error']
- Bert -
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners