[Pharo-project] startup errors
a.bruehlmann at netstyle.ch
Wed Oct 26 05:51:51 EDT 2011
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?
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
Igor Stasenko schrieb:
> On 25 October 2011 23:26, Schwab,Wilhelm K <bschwab at anest.ufl.edu> wrote:
>> 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.
>> From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua at gmail.com]
>> Sent: Tuesday, October 25, 2011 9:40 AM
>> To: Pharo-project at lists.gforge.inria.fr
>> Subject: Re: [Pharo-project] startup errors
>> On 24 October 2011 11:40, Andrea Brühlmann <a.bruehlmann at netstyle.ch> 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?
>>> 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
>>>> 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
>>>> 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.
>> 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 · A.BRUEHLMANN at NETSTYLE.CH
More information about the Pharo-dev