Ben, (this is a bit off-topic)
do you happen to know the purpose of that pre-debug-window? I must say that I find it annoying every time I get it in Pharo or VA? Why doesn't the debugger show up immediately? But your suggestion is a good one, imo. In the startup phase of an image, the image might not be ready to provide any means of reacting to a problem, so why bother showing errors that early? What you describe should be quite easy to achieve with a handler that records and resumes errors during startup. Joachim Am 08.11.2017 03:54 schrieb Ben Coman <b...@openinworld.com>: > > > > On Wed, Nov 8, 2017 at 10:16 AM, Sean P. DeNigris <s...@clipperadams.com> > wrote: >> >> In a headless image, I'd like to do the following: if there's any error, >> arrange to have a debugger open on the next (headful) launch, and then save >> and quit. >> >> I'm drawing a blank - how would I do that? >> >> I explored various dead ends, the culmination of which was the >> image-breaking: >> actualWorkBlock on: Error do: [ [ Smalltalk snapshot: true andQuit: true ] >> fork. Halt now ] >> >> Thanks! > > > Sorry not a solution, but you sparked a side-thought... To avoid sometimes > being swamped by Pre-Debug windows. Instead of an error bringing up an > individual Pre-Debug window, we could have error go into a queue which a > singleton Pre-Debug window could have a view into. This "Error Queue Viewer" > would have on row per error, and you click on a row to open a normal > debugger, much like you click <Debug> button in the existing Pre-Debug > window. In a headless image, the Error Queue Viewer would not appear, but > the error would keep being queued until the next time the Error Queue Viewer > is manually opened. The same error-queue might provide a similar interface > point for Pharo Remote Tools, so you can see errors that occurred while you > were not connected. > > cheers -ben
