> On Dec. 17, 2013, 5:22 p.m., Alan Conway wrote:
> > /trunk/qpid/cpp/src/qpid/messaging/Logger.cpp, line 68
> > <https://reviews.apache.org/r/16316/diff/1/?file=398793#file398793line68>
> >
> >     That's really, really weird. I had no idea you could omit the braces in 
> > a function definition in any circumstances. Can you do it with anything 
> > other than try/catch? I tried a few things and none worked.
> >     
> >     I think the extra braces might prevent a lot of head-scratching even if 
> > they are ugly.
> 
> Andrew Stitcher wrote:
>     Yes, it only works with a try block.
>     
>     As I said above it's not really necessary here (but I like it dammit, and 
> it's been in the language a long time now).
>     
>     It should really be better known for the following (real) use:
>     
>     The real use case is catching exceptions from initialisers in a 
> constructor viz.
>     
>     Class::Class()
>     try :
>       object_with constructor_that_might_throw(42)
>     {}
>     catch (std::exception e) {
>       throw MyClassException(e.what());
>     }
>     
>     That looks even more weird, but get used to it, because it is the only 
> way to catch exceptions in constructor initialisers (and in fact you need 
> something like this to catch exceptions in implicitly called constructors 
> even with no explicit initialiser list)
>

Curiouser and curiouser. I love how C++ is able to solve any problem simply by 
making the language more complicated :)
Leave it in, it'll be educational.


- Alan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16316/#review30543
-----------------------------------------------------------


On Dec. 17, 2013, 5:02 p.m., Andrew Stitcher wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16316/
> -----------------------------------------------------------
> 
> (Updated Dec. 17, 2013, 5:02 p.m.)
> 
> 
> Review request for qpid, Chug Rolke and Gordon Sim.
> 
> 
> Bugs: QPID-5415
>     https://issues.apache.org/jira/browse/QPID-5415
> 
> 
> Repository: qpid
> 
> 
> Description
> -------
> 
> Currently there is one major omission from the qpid::messaging API: That is 
> control of the internal logging used by qpid itself.
> 
> This was previously present in the qpid::client API albeit not really 
> supported or documented. Now that we have completely removed the qpid::client 
> and associated APIs from being exported for use beyond qpid itself there is 
> no way to control the logging internal to the qpid messaging libraries.
> 
> This review introduces some simple APIs which give back control of the qpid's 
> internal logging. I think there is now as much control as virtually all qpid 
> user applications are likely to need.
> 
> Please give the proposed API some consideration and let me know if there is 
> anything that an application needs that I haven't considered here.
> 
> 
> Diffs
> -----
> 
>   /trunk/qpid/cpp/include/qpid/messaging/Logger.h PRE-CREATION 
>   /trunk/qpid/cpp/src/CMakeLists.txt 1551560 
>   /trunk/qpid/cpp/src/qpid/log/Logger.cpp 1551560 
>   /trunk/qpid/cpp/src/qpid/log/Options.h 1551560 
>   /trunk/qpid/cpp/src/qpid/log/Options.cpp 1551560 
>   /trunk/qpid/cpp/src/qpid/log/Selector.cpp 1551560 
>   /trunk/qpid/cpp/src/qpid/log/Statement.cpp 1551560 
>   /trunk/qpid/cpp/src/qpid/messaging/Logger.cpp PRE-CREATION 
>   /trunk/qpid/cpp/src/tests/CMakeLists.txt 1551560 
>   /trunk/qpid/cpp/src/tests/MessagingLogger.cpp PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/16316/diff/
> 
> 
> Testing
> -------
> 
> Added in unit tests which pass*
> 
> *They currently also assume a bug fix which is included in the code in this 
> review which prevents critical log messages ever being turned off (I think 
> this the correct behaviour - in the current code under some circumstances 
> they can actually be turned off)
> 
> 
> Thanks,
> 
> Andrew Stitcher
> 
>

Reply via email to