There is a ban on a rename operation while in debugger while renaming some subset of tcl commands, like puts. My application renames puts, so it was broken by the debugger. But I had no information about the failure until I enabled "stop on all errors". I think it would be reasonable to break unconditionally in this situation, because I think most applications that use rename won't work properly if rename is not executed, and this error should be considered at least very serious, if not fatal.
So in my fork I added a break dialog in this place, so the code fragment now looks like this:
if {![DbgNub_okToRename $name $level]} {
puts "cannot rename \"[lindex $args 0]\" in the debugger, your application is likely broken!"
# this won't stop if we are inside catch or chosen to not stop on errors, so we break
DbgNub_Break $level error "Who on earth reads this message?" "Debugger limitation: cannot rename \"[lindex $args 0]\" in the debugger" 1 1
return -code 1 \
"cannot rename \"[lindex $args 0]\" in the debugger"
}
There is a ban on a rename operation while in debugger while renaming some subset of tcl commands, like
puts. My application renamesputs, so it was broken by the debugger. But I had no information about the failure until I enabled "stop on all errors". I think it would be reasonable to break unconditionally in this situation, because I think most applications that use rename won't work properly if rename is not executed, and this error should be considered at least very serious, if not fatal.So in my fork I added a break dialog in this place, so the code fragment now looks like this: