[Pharo-project] startup errors

Andrea Brühlmann 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 
something.

Andrea

Igor Stasenko schrieb:
> On 25 October 2011 23:26, Schwab,Wilhelm K <bschwab at anest.ufl.edu> 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: 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?
>>>
>>> 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 · A.BRUEHLMANN at NETSTYLE.CH




More information about the Pharo-dev mailing list