On 26 October 2011 11:51, Andrea Brühlmann <[email protected]> wrote: > I tried it with this option now, but it did not solve the problem, because > it just saved a new version of the image and quit, but did not open a > debugger. Opening the new version does the same as the original. Did I miss > something? > It should open a debugger. if not, then this is a bug :) It might be, that if error happens in startup phase, then it is not opens a debugger.
> I would appreciate a command line option that either opens a debugger or > ignores the errors, because like this you usually have a clean image but if > you have a problem, you can open the image and do something. > > Andrea > > Igor Stasenko schrieb: >> >> On 25 October 2011 23:26, Schwab,Wilhelm K <[email protected]> wrote: >>> >>> Sig, >>> >>> All too true, and very pure. But what if I just want to save a package, >>> or some data, that might be locked away in the image? Code is generally >>> safe, since one can recover lost changes into a healthy image, but there can >>> still be other data lurking in an image. >>> >>> A middle-ground approach would be to have command line option that lets >>> the image run. One should run w/o it to bring errors to attention, but at >>> least it would be possible to override and at least have an opportunity to >>> recover endangered bits. >>> >> look at settings, there's already an option to save a new version of >> image before quit. >> if you turn this option on, then any unhandled error will open a >> debugger if you open an image saved in such state. >> >>> Bill >>> >>> >>> ________________________________________ >>> From: [email protected] >>> [[email protected]] On Behalf Of Igor Stasenko >>> [[email protected]] >>> Sent: Tuesday, October 25, 2011 9:40 AM >>> To: [email protected] >>> Subject: Re: [Pharo-project] startup errors >>> >>> On 24 October 2011 11:40, Andrea Brühlmann <[email protected]> >>> wrote: >>>> >>>> It seems that pharo 1.3 introduced that the image quits if an error >>>> happens >>>> during startup. What are the reasons for this? >>>> >>> The reasons are simple: >>> if image fails to startup properly, there are no way to tell, if some >>> services initialized properly or not (UI is one of them), >>> and so, there are no any guarantees that image could run safely. >>> So, the best thing which you can do is to write error to log and quit. >>> >>> This is because startup manager knows what to start-up and in what >>> order, but it doesn't knows, how critical a given service for properly >>> running the whole image. Therefore, if you don't handle startup errors >>> in your service code, a startup manager has no other choice , but just >>> leave to OS. >>> >>> >>>> Or what's the state of the email below? >>>> >>>> Andrea >>>> >>>> >>>> Camillo Bruni schrieb: >>>>> >>>>> While working on Coral we encountered a rather annoying behavior of >>>>> pharo >>>>> images when starting up. >>>>> >>>>> We wanted to check if we can debug the CoralScriptLoader, but of corse >>>>> since this happens at image startup time this is not a good idea… >>>>> HOWEVER we >>>>> were no longer able to run the image as it immediately crashes during >>>>> the >>>>> startup. >>>>> >>>>> Now I wonder if it would make sense to add a couple of on:do: in >>>>> SmalltalkImage >> snapshot:anQuit: to collect the errors of all the >>>>> startup >>>>> scripts and then only show them after all other startupListItems are >>>>> processed. >>>>> >>>>> All in all the behavior would not much differ from what is going on >>>>> right >>>>> now, but would prevent stupid users like me from losing a whole image. >>>>> >>>>> camillo >>>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >>> >> >> >> > > -- > AB | ANDREA BRÜHLMANN · SOFTWARE ENGINEER > | NETSTYLE · TERRASSENWEG 18 · CH-3012 BERN > | TEL +41 31 356 42 54 · FAX +41 31 356 42 51 > | WWW.NETSTYLE.CH · [email protected] > > -- Best regards, Igor Stasenko.
