- Which exception for a buffer overrun? - 9 Updates
| doctor@doctor.nl2k.ab.ca (The Doctor): Oct 17 12:15AM In article <05047d4c-6f30-4c4a-9c55-78e4e38516ee@googlegroups.com>, ร รถ Tiib <ootiib@hot.ee> wrote: 57 lines no content. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism Canada - Choose Forward on 21 Oct 2019 ! |
| Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Oct 17 03:31AM +0100 On 17/10/2019 01:15, The Doctor wrote: > In article <05047d4c-6f30-4c4a-9c55-78e4e38516ee@googlegroups.com>, > � ö Tiib <ootiib@hot.ee> wrote: > 57 lines no content. There seems to be a general problem the last several hours - I've seen dozens of "no content" posts. They all seem to be Google Groups posters, but possibly it's also related to my newsgroup servre (my ISP uses GigaNews). The original messages are there on Google Groups.. Mike. |
| Ian Collins <ian-news@hotmail.com>: Oct 17 03:35PM +1300 On 17/10/2019 15:31, Mike Terry wrote: > dozens of "no content" posts. They all seem to be Google Groups > posters, but possibly it's also related to my newsgroup servre (my ISP > uses GigaNews). The original messages are there on Google Groups.. Must be a GigaNews problem, everything is fine on news.individual.net. -- Ian. |
| Daniel <danielaparker@gmail.com>: Oct 16 08:06PM -0700 On Wednesday, October 16, 2019 at 5:00:47 PM UTC-4, David Brown wrote: > Correct me if I am wrong, but for the most part the only exception that > will be thrown by the standard library is for failed memory allocations. I don't think you can count on that. One example, implementations of basic_streambuf::overflow are allowed to throw on failure. Daniel |
| David Brown <david.brown@hesbynett.no>: Oct 17 10:14AM +0200 On 16/10/2019 23:36, Ian Collins wrote: > function have to be, for lack of a better term, self managing. This is > what applies equally to code with early returns and throws. Early > return safe and exception safe are pretty much synonymous. Yes, I see what you mean. From the other viewpoint, it means you get the advantages and safety of RAII without having to use exceptions - RAII classes are still an excellent way to structure a lot of code. But again, with early returns you have more control - you can decide how early to return, meaning you don't have to have make the parts self-managing with RAII if it doesn't make sense in the program structure. (And by "early returns", that includes any kind of failure handling through return values.) > if a constructor of the type being inserted throws. That's why I said > we have to build (every component of an application) with exceptions > disabled to truly grantee something won't throw. If you are not throwing exceptions in your own classes, then insertions won't throw, because constructors won't throw. Of course, whether you can build the whole application with exceptions disabled, and whether that is a good idea, is going to depend on the type of application and the mix of code you have. |
| David Brown <david.brown@hesbynett.no>: Oct 17 10:17AM +0200 On 17/10/2019 04:35, Ian Collins wrote: >> posters, but possibly it's also related to my newsgroup servre (my ISP >> uses GigaNews). The original messages are there on Google Groups.. > Must be a GigaNews problem, everything is fine on news.individual.net. I'm getting the blank messages on news.eternal-september.org also. Maybe they get their feed from GigaNews, or maybe the problem is wider. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 17 06:34AM -0700 On Wednesday, 16 October 2019 17:12:40 UTC+3, David Brown wrote: > return true; > How do you make that into an exception-based handling, with "tryThis" > throwing an exception on failure? Thanks. I will try to explain how I would approach it. Not sure if my post will show up though if there is some GG error. First, the doThisAnyway() feels a bit like some close/release/erase/reset kind of clean-up-after-work function. It is preferable to bind those into destructors together with RAII like one of your examples did. Also if the tryThis() is of "cleanup" kind (usually such calls are done together) then it preferably should not throw in C++. Things that may be called in destructors should indicate failures by other means in C++ since standard library expects that destructors, operator deletes and swaps don't throw. If neither is cleanup function then it feels unusual. What it is that is reasonable to do anyway regardless if previous steps failed? I can live with duplicate code or with keeping the tryThis() non-throwing or with making indeed some destructor-based "defer" for calling doThisAnyway() but ... the whole situation feels interesting. > With explicit, manual control of the errors or unusual circumstances, it > can be easier to see the flow of the code. It can make the actual algorithm harder to read. We need to add failed state to all objects whose constructors or operators may fail. Checking those is code. The actual reasons of failure are often abstracted away by such "failed" state. A template can't be even expected to know all failures that the objects it manipulates can face, so how it can pass the information up intact? Exceptions are harder to miss and can carry more information. > I am not saying that exceptions /always/ make code harder to read - far > from it. I am merely saying that /sometimes/ they do. There I agree, I have seen very lot of code that was made bad with exception handling. The reason is usually lack of skills, strategies and policies. People should read the 31 suggestions from core guidelines: <http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#S-errors> as minimum before using exceptions. > performance reasons, partly for clarity, partly due to limited support > for some targets, partly due to a mix of C and C++ code. This limits my > experience of C++ exceptions.) I understand it so that in embedded development there it is usually just not enough power to pass sophisticated error handling information around and also the total number of possible fatal failures is so low that each can have personalized bit for it reserved in some int (or couple). > And of course with C++ you have all the power of RAII, and tools like > std::unique_ptr - you don't need exceptions to use them. They apply > equally well to exiting functions with an early return. When failure means that caller has anyway not much to do with more information then early false is fine and then the code can be ok. However the error-handling policies often require that way more information (potentially dynamic and structured) is passed up about nature of failure. |
| David Brown <david.brown@hesbynett.no>: Oct 17 04:34PM +0200 On 17/10/2019 15:34, Öö Tiib wrote: >> throwing an exception on failure? > Thanks. I will try to explain how I would approach it. Not sure if my post > will show up though if there is some GG error. It showed up for me, anyway. And that's all that matters :-) > First, the doThisAnyway() feels a bit like some close/release/erase/reset > kind of clean-up-after-work function. It is preferable to bind those into > destructors together with RAII like one of your examples did. If it is a pure cleanup, then RAII is likely to be the best way. But maybe it is not pure - perhaps it is using some data that is local in the function, or maybe it is a debug/log function that you don't want to be part of a "tryThis" object. I am quite happy to accept that often any kind of "doThisAnyway" code would naturally fit in an RAII destructor - we are considering the situation where for some reason, it is more natural, logical or maintainable to have it inside the main code. > deletes and swaps don't throw. > If neither is cleanup function then it feels unusual. What it is that is > reasonable to do anyway regardless if previous steps failed? Perhaps informing some other part of the system (or the user) of the progress? > live with duplicate code or with keeping the tryThis() non-throwing > or with making indeed some destructor-based "defer" for calling > doThisAnyway() but ... the whole situation feels interesting. Yes, sometimes duplicate code is the simplest and clearest solution. > to know all failures that the objects it manipulates can face, so how > it can pass the information up intact? Exceptions are harder to > miss and can carry more information. A "success bool" carries all the information it needs (if a pass/fail indication is all that is needed), and won't be missed. Optionals, variants, expecteds, are all other related solutions with more flexibility. And yes, templates /can/ be made to handle these. > information around and also the total number of possible fatal > failures is so low that each can have personalized bit for it > reserved in some int (or couple). Yes. Modern microcontrollers are often big enough and powerful enough to handle exceptions, but supporting exceptions can be costly. It rarely matters on a PC if unwind tables adds 30% (taking a rough figure out of the air) to the code space - probably it's still a drop in the ocean compared to the graphics files and other non-code data in the application, and your computer has almost unlimited disk space anyway. 30% bigger code space is a lot more significant when you have 256 KB of flash. There are many other reasons too. Often in embedded systems, you are concerned about worst-case performance - the last thing you want is a code path that takes a long and unpredictable time. You might not want dynamic memory at all (or at least, you need to minimise it, or control it with dedicated memory pools) - an exception system with unknown numbers of exceptions floating around is not appropriate. (Again, static exceptions might fix this.) And often you simply design your functions so that they cannot fail - if failure is not an option, you don't need exceptions. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 17 09:22PM +0200 > They are a bad idea for normal processing as an alternative to return > values. When you know that the exception would always address the caller, you can stick with return-values anyway. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment