Like Tree6Likes

Exceptions in constructor..

This is a discussion on Exceptions in constructor.. within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by phantomotap If the creation of 'L1' is almost free, as it certainly will be if it is ...

  1. #16
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    Quote Originally Posted by phantomotap View Post
    If the creation of 'L1' is almost free, as it certainly will be if it is just initializing a few pointers to null, the cost of that object is trivial.
    The 'list' is a singly linked list which may contain other lists or just string values.
    So creating is just allocating to sentinel nodes..(It could be made into nullptrs if required though..)

    As construction is all or nothing, we can see that 'L2' (and thus 'L1') will not be modified if the string can't be parsed correctly.

    If the members of the `list' objects are swapped, instead of using a potentially expensive copy operation, the construction is "free" in that we will continue using those elements as referenced from 'L2' (and thus 'L1').

    The function is clear and concise. (Though the name is verbose here for other purposes.)
    Good idea... I'll do so.


    Quote Originally Posted by grumpy View Post
    The constructor is only invoked because you are choosing to invoke it in your is_list() function. If there is some realistic option to inexpensively check the string (without creating a list) then THAT is what you need to do in the is_list() function.

    If there is no such realistic option, and you care as much as you (apparently) do about parsing the string more than once, or how many times the constructor runs, then you only need the single constructor.

    All that then requires is that the user of your class always attempt to create an object, and then handles (or propagates) any exception that is thrown.
    The checking can't be less complicated than creating...I think.
    As.. "(1 2 3 4)" and "(()(a b c)((1 2 3 4)(x y z)))" are both valid for constructing the list.
    Last edited by manasij7479; 01-03-2012 at 01:53 PM.
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  2. #17
    Registered User
    Join Date
    Jun 2005
    Posts
    6,200
    Hence, my advice is that you only have the one throwing constructor, and don't bother with the is_list() function.
    Right 98% of the time, and don't care about the other 3%.

  3. #18
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,293
    All of grumpy's replies are exactly how to implement RAII. It would be good to follow them.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  4. #19
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,235
    If a constructor can fail without throwing an exception, then the destructor will have to deal with destroying an object that wasn't successfully constructed. This increases complexity and the probability of a bug.

    Unless you have a solid design requirement which forbids exceptions ("I don't like them" is not a valid reason), use exceptions to communicate constructor failure.

    I have to work in a codebase that forbids exceptions. I'm really not sure how to put into words how much that sucks. At least the reason why is a legitimate reason, though.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  5. #20
    Registered User
    Join Date
    Jun 2005
    Posts
    6,200
    Quote Originally Posted by brewbuck View Post
    I have to work in a codebase that forbids exceptions. I'm really not sure how to put into words how much that sucks. At least the reason why is a legitimate reason, though.
    Out of curiosity, what is that "legitimate reason"?
    Right 98% of the time, and don't care about the other 3%.

  6. #21
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,235
    Quote Originally Posted by grumpy View Post
    Out of curiosity, what is that "legitimate reason"?
    We develop an SDK which is used in certain kinds of software drivers. Those drivers are subjected to automated testing with a well-known test framework by a well-known company. The particular tests which these drivers are subjected to, will consider the throwing of any exception of any type to be a failed test. The drivers must pass the tests. If our SDK throws exceptions, the drivers fail the tests and they cannot use our SDK.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  7. #22
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,410
    Quote Originally Posted by brewbuck
    If our SDK throws exceptions, the drivers fail the tests and they cannot use our SDK.
    Can't you just enforce the rule that exceptions must not be allowed to propagate beyond module boundaries, in this just the module boundary being the public interface of the SDK?
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  8. #23
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,235
    Quote Originally Posted by laserlight View Post
    Can't you just enforce the rule that exceptions must not be allowed to propagate beyond module boundaries, in this just the module boundary being the public interface of the SDK?
    Doesn't work. The third party test framework is looking for exceptions being THROWN, not uncaught exceptions.

    Funny story how we initially discovered this unstated requirement. The code was already written to not use exceptions (for dogmatic reasons only). Then we were shown a weird failure on this test bench -- remember, we're just a component in someone else's code -- and it seemed to be caused by an exception thrown by our own code.

    Of course, that couldn't be true as we do not use exceptions. Eventually we tracked the problem to a failed memory allocation via no-throw operator new, an allocation we were making. The reason the allocation was failing is also a funny story but can't be repeated here. Okay, what the heck. The test is popping because of an exception generated by no-throw new? Yes. The C++ runtime had implemented no-throw new by wrapping throwing new in a try-catch and returning NULL if an exception was thrown.

    The fix? Override all the standard library's new and delete operators to call malloc() directly and simply return NULL on failure, rather than generating, then absorbing, an exception, completely internally.
    whiteflags likes this.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  9. #24
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,167
    The third party test framework is looking for exceptions being THROWN, not uncaught exceptions.
    O_o

    That's bizarre on so many levels.

    I wonder, are you able to explain why this is a condition for passing? (I appreciate that you may not be able to discuss it for whatever reason. I'm just very extremely curious.)

    Soma

  10. #25
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,235
    Quote Originally Posted by phantomotap View Post
    O_o

    That's bizarre on so many levels.

    I wonder, are you able to explain why this is a condition for passing? (I appreciate that you may not be able to discuss it for whatever reason. I'm just very extremely curious.)

    Soma
    I think it's not really intentional. A debugger is attached to the process being tested, the debugger is configured to automatically break when any of a large number of weird conditions happens, the throwing of an exception being one of them. I don't think there is an explicit requirement that exceptions be avoided, the rule is just "If the debugger breaks in you fail."

    We filed a bug with the maker of the test harness. Might as well have filed it with the Pope.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 5
    Last Post: 02-21-2011, 01:19 AM
  2. Specialized Constructor call Default Constructor
    By threahdead in forum C++ Programming
    Replies: 15
    Last Post: 08-23-2010, 03:39 PM
  3. Replies: 6
    Last Post: 05-19-2010, 04:03 AM
  4. default constructor == constructor without argument?
    By cyberfish in forum C++ Programming
    Replies: 6
    Last Post: 04-15-2009, 03:25 AM
  5. Replies: 10
    Last Post: 06-02-2008, 08:09 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21