[zeromq-dev] Improving zeromq in OOM conditions

[Amr Ali]

I completely agree too, I've built a proprietary system that relies heavily on
0MQ and concurrency is a must, tried to implement exception so that they
propagate vertically and send feed back horizontally and juggling in between 5
components 4 of which can have hundreds of duplicates for parallelization and
load-balancing. One thing I learned, exceptions just can't do it!

They can be very useful in a limited scope that doesn't have near real-time
performance as a goal, but very confusing and becomes almost unpredictable in a
large setup, that and it requires much cognitive power to keep track of what
throws and what doesn't in a larger picture of things.

On 05/16/2011 03:05 PM, Fabien Ninoles wrote:
> Also, in the gaming industry, most of our stuff have exception deactivated.  Performance is the main reason here:  exception create an overhead that isn't compensate by error handling (error handling ?  in a game ?  what's that ? ;) ).
> 
> Fabien
> 
> -----Message d'origine-----
> De : zeromq-dev-bounces at lists.zeromq.org [mailto:zeromq-dev-bounces at lists.zeromq.org] De la part de Martin Sustrik
> Envoyé : 16 mai 2011 06:12
> À : ZeroMQ development list
> Cc : Ilja Golshtein
> Objet : Re: [zeromq-dev] Improving zeromq in OOM conditions
> 
> Hi Ilja,
> 
>> Could someone please explain why catching exceptions is dissalowed.
>> Or "discouraged" has less strong meaning?
> 
> The problem is exceptions is that they make failure execution paths 
> almost pretty blurry. When you throw an exception, it's basically 
> impossible to find out who's (if at all) is going to catch it etc.
> 
> Exceptions are great for low reliability systems (GUIs and alike) but 
> are not very good for systems that are supposed to be highly reliable. 
> Error handling should be as explicit as possible in the latter case.
> 
>> Strong paradigms (like don't use delete, don't catch exceptions) are
>> fine for students' works, not for real things.
> 
> The paradigm we use is well-established C paradigm ("return an error code").
> 
> On a different topic: The dependency on STL is pretty weak and can 
> possibly be removed as part of the OOM work (fixed size containers 
> instead of resizeable containers etc.) thus getting rid of exceptions 
> entirely.
> 
> Martin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110516/a7de078c/attachment.sig>