On 4 August 2012 04:11, Ben Coman <[email protected]> wrote:
As probably many newbies do from time to time, I am learning the system
splattering 'self halt' around, and once again slipped one into the wrong
place where I should have used 'haltOnce' and had a massive number of
pre-debugger windows come up. I managed to get it back this time with
the
user interrupt - but not always - and anyhow clearing so many debug
windows
is a pain. So..... could 'self halt' be made to monitor the rate that
the
halt windows appear, and when more than some value from one of them (say
five per second) it starts getting ignored and shows a dialog asking the
user if they really meant this and enable danger mode, or if they screwed
up
and want to revert the method containing the suspect 'halt'.
If we look from user's perspective (not machine perspective), apparently
it is pointless to throw so many messages at the user's face, because
he cannot deal with them
in meaningful manner at such rate.
So, i think there should be something like following:
- if exception requires a user interaction, we do show the popup, but
meanwhile remember
the exception which initiated it.
- if there's next exception incoming and also asks UI manager to show
it to user, we queue it,
letting user to deal with first one.. (or we delay the popup , say 1
each 5 seconds).
and finally, a queue should have some reasonable limit, after which we
stop queuing , because again, user certainly won't be willing to waste
his time dealing with 10000000 exceptions of same kind one by one. It
doesn't makes sense anyways.
In such case we can just ignore halt and let program continue (but
increment some counter to show user how many of them are there).
If exception is different (an Error) then on queue overflow, i think
it should terminate the process with exception (but of course, special
care must be taken if process is UI process).
Of course making it too smart is pointless, because it is impossible
to predict whether it is good idea
to terminate process or letting it continue to run in case of exception.
But for that we can have settings and options, to tune that at user's
discretion, as well as default
settings on a per-exception class base.
anyhow, just musing.... -ben
i know by myself how annoying it can be (up to unresponsive image)
and i think most of us is facing such situation time to time (heh..
just yesterday we had it with Camillo while hacking ocompletion
stuff).
i learned to be careful and avoid such situations.. but sometimes it
is hard and better tooling support will be helpful, no doubt.