[zeromq-dev] Improving zeromq in OOM conditions
fabien.ninoles at ubisoft.com
Mon May 16 15:05:58 CEST 2011
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 ? ;) ).
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
> 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
zeromq-dev mailing list
zeromq-dev at lists.zeromq.org
More information about the zeromq-dev