[Harald Oehlmann <harald.oehlmann@el...>]

Hi Serg,

thank you for the proposal. I don't like not supporting new ideas, which
are always good.
Nevertheless, here is my answer.

The proposition is to:
- stock the error if it arises
- throw it if "fconfigure -throwerror" is executed.

The functionality you require is more appropriately covered by "fileevent".
For instance, fileevent (readable,writable) fires in success and fail
cases. If you want an error fileevent only, this should be extended.

Your proposed change is IMHO quite heavy in implementation.

The proposed "fconfigure -throwerror" is 5 lines in C code, as the whole
functionality is already awaylable by "fconfigure -error".

Ok ?

Thank you,
Harald


Am 24.04.2014 17:14, schrieb Dipl. Ing. Sergey G. Brester:
> Am 24.04.2014 15:59, schrieb Harald Oehlmann:
> 
> Hello Harald, everyone.
> 
> Do I understand correctly, did you mean boolean switch, something like
> "fconfigure -throwerror *yes|no*"?
> 
> If yes, it'll be good solution imho (source code maintenance, backwards
> compatibility etc.).
> 
> But imho, better solution would be something like example below:
> 
> *fconfigure $chan1 -onerror on_chan_error
> fconfigure $chan2 -onerror on_chan_error_throw*
> 
> proc *on_chan_error* {chan opt msg} {
>   # log error message:
>   tclLog ... $msg
>   # rethrow an error:
>   return {*}$opt $msg
> }
> 
> proc *on_chan_error_throw* {chan args} {
>   # simple rethrow an error:
>   return {*}$args
> }
> 
> So we can define a callback, that just rethrows an error (return) or
> does additionaly anything else (tcLog).
> For example, it make possible to (re)connect, if we have a connection
> problems or still much more other cases...
> 
> I think, the cost of implementation of this would be comparable with
> throwing of error, because the error message+options you should buffers
> nevertheless up to the channel access.
> 
> Regards,
> 
> Serg
> 
>> Am 22.04.2014 14:26, schrieb Donal K. Fellows:
>>> Hi everyone As you can see, TIPs 427 and 428 are now up. The delay in
>>> publishing them was due to me having a total crunch on at work (since
>>> Christmas it's been a neverending round of too many things to do, not
>>> nearly enough time, and *far* too much stress!) for which I
>>> completely and unreservedly apologise.
>> Donal, TCL-community,
>>
>> thank you bringing the TIPs up and caring well about language and form.
>> Complementary information is on the wiki page http://wiki.tcl.tk/39687
>>
>> Some information to the community and possible ways how things may be done:
>>
>> - TIP#427: "Introspection of Asynchronous Socket Connection"
>>
>> This TIP proposes "fconfigure -connecting" which allow to fully use
>> async connect without the event queue.
>> Async connect without event queue worked well on TCL8.5 and was used
>> (info by windows bug reports).
>>
>> How this may proceed:
>> - Reinhard wants to review the TIP
>> - After discussion, this small change may be voted and integrated in tcl
>> 8.6.2
>> - eventually backport to tcl 8.5 (open for discussion)
>>
>> - TIP#428: Produce Error Dictionary from 'fconfigure -error'
>>
>> This second tip has a more general form and question.
>> I want to rewrite it totally as something like:
>> "fconfigure -throwerror" : if an error arised in a non-blocking
>> operation (e.g. "fconfigure -error" would report an error), throw this
>> error. If there is no error, do nothing.
>>
>> This would allow to treat a background error like a normal error and do
>> a catch or a try on it and get errorCode etc.
>>
>> It has a more general scope, as other channel drivers also implement the
>> option "fconfigure -error" and thus should also support this.
>>
>> Please feel free to comment.
>>
>> Harald
>>
>>
>> ------------------------------------------------------------------------------
>> Start Your Social Network Today - Download eXo Platform
>> Build your Enterprise Intranet with eXo Platform Software
>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> http://p.sf.net/sfu/ExoPlatform
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl-Core@... <mailto:Tcl-Core@...>
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
> 
>  
> 


-- 
ELMICRON Dr. Harald Oehlmann GmbH
Koesener Str. 85
06618 Naumburg
Germany
Phone: +49 (0)3445 78112-0
Fax: +49 (0)3445 78112-19
 http://www.Elmicron.de
German legal references:
Geschaeftsfuehrer: Dr. Harald Oehlmann, Jens Oehlmann
UST Nr. / VAT ID No.: DE206105272
HRB 212803 Stendal