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 : [email protected] > [mailto:[email protected]] 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
signature.asc
Description: OpenPGP digital signature
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
