Re: [RFC] --disable-panics configuration option

So all libraries should actually issue error instead of panic, because 
libraries
cannot know is error fatal or not ? (But the error looks severe, 
however).

Simple change would be easy to implement, and Jon is not only one 
getting
strange octstr panics.

Aarno

On 24.3.2005, at 00:12, Stipe Tolj wrote:

> Aarno Syvänen wrote:
>
>> And I cannot agree more, actually. But auditing takes time. Until
>> it is done, --disable-panics will be of some use.
>
> now, yes, auditing takes some time. But it's the way to go, IMO. 
> Simply adding a configure switch would cause in unstable internal 
> state if a function hits the panic() button and we keep the beast 
> running, since the logic has in mind that the beast is supposed to die 
> now.
>
> You could #idef things inside panic() to prevent it from panic'ing, if 
> it's up for a fast solution.
>
> If we add the configure switch, I almost see "unnecessary" bug reports 
> rushing in that have their cause from such situations. Which I'd like 
> definetly to prevent.
>
> Hence, -0 to -1 in simply "blind-mode" preventing panic() stops here. 
> +1 on auditing and making Kalle's dream come true: a genuine panic() 
> policy ;)
>
> Stipe
>
> mailto:stolj_{at}_wapme.de
> -------------------------------------------------------------------
> Wapme Systems AG
>
> Vogelsanger Weg 80
> 40470 Düsseldorf, NRW, Germany
>
> phone: +49.211.74845.0
> fax: +49.211.74845.299
>
> mailto:info_{at}_wapme-systems.de
> http://www.wapme-systems.de/
> -------------------------------------------------------------------
>