Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #69268
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: Which exception for a buffer overrun? |
| Date | 2019-10-17 10:14 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <qo97u2$de3$1@dont-email.me> (permalink) |
| References | (4 earlier) <qo5ffc$fpe$1@dont-email.me> <qo6jls$hog$1@dont-email.me> <h0p8ijF41nU1@mid.individual.net> <qo80dd$pn6$1@dont-email.me> <h0pgq8F41nU2@mid.individual.net> |
On 16/10/2019 23:36, Ian Collins wrote: > On 17/10/2019 10:00, David Brown wrote: >> On 16/10/2019 21:15, Ian Collins wrote: >>> On 16/10/2019 21:16, David Brown wrote: >> >>>> Readability is of course very important - and code correctness even >>>> more >>>> so. However, I am not convinced that exceptions are a great >>>> correctness >>>> feature. It is hard to write fully exception-safe code. And, >>>> worse, it >>>> is easy to write code that /appears/ to be exception safe, but is not. >>>> >>>> The two key problems, as I see it, are first that exceptions means all >>>> sorts of code (function calls and expressions) can fail unexpectedly at >>>> any time, leading to early returns from your function. You have to be >>>> thinking all the time about what will happen if there is an exception >>>> when the code runs. This can mean making more RAII classes, or more >>>> indirect references (via unique_ptr, for example), simply to ensure >>>> cleanup in case functions throw an exception. That will make the code >>>> safe and correct - but can be of significant readability cost. >>> >>> The same set of conditions also apply to code that uses early returns. >>> Throwing an exception is just a special case of an early return. >> >> There are two big differences. One is that with an early return, >> everything is clear in the code - you know /exactly/ when the return >> happens, without having to consider whether functions may or may not >> throw. The second is that you have control of the return - you can >> choose if it is early, or if other things are done first. > > I was mainly responding to more of the "This can mean making more RAII > classes" section. Once you have early returns, objects instantiated in a > 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.) >>>> The other problem is that a lot of the information about C++ exceptions >>>> that a function can throw, is basically lying. You can /say/ that a >>>> function only throws specific exception types, which would be very >>>> useful, but it's a lie. At least C++11 "noexcept" is a stronger, and >>>> now "throw" specifications are no longer part of C++17 at all. But >>>> there is currently no way to say what exceptions a function really >>>> could >>>> throw, no way to check such features at compile time, no integration >>>> with the type system, and the default is for functions to be specified >>>> as "this function could throw anything, or pass on any exception" >>>> rather >>>> than the more sensible "this function won't throw - it will do what it >>>> says it will do". >>> >>> This is true, but we are already there when we use the standard library >>> unless we build with exceptions disabled. >>> >> >> 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. > > That is true, but even innocuous operations such as insertions can throw > 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.
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Which exception for a buffer overrun? Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-10-15 03:00 -0700
Re:Which exception for a buffer overrun? melzzzzz <mel@melzzzzz.com> - 2019-10-15 12:52 +0200
Re: Re:Which exception for a buffer overrun? queequeg@trust.no1 (Queequeg) - 2019-10-16 12:52 +0000
Re: Re:Which exception for a buffer overrun? melzzzzz <mel@melzzzzz.com> - 2019-10-16 18:29 +0200
Re: Which exception for a buffer overrun? Paavo Helde <myfirstname@osa.pri.ee> - 2019-10-15 13:54 +0300
Re: Which exception for a buffer overrun? Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-10-15 04:08 -0700
Re: Which exception for a buffer overrun? David Brown <david.brown@hesbynett.no> - 2019-10-15 13:57 +0200
Re: Which exception for a buffer overrun? Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-15 23:59 +0200
Re: Which exception for a buffer overrun? scott@slp53.sl.home (Scott Lurndal) - 2019-10-15 22:13 +0000
Re: Which exception for a buffer overrun? Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-16 15:04 +0200
Re: Which exception for a buffer overrun? Paavo Helde <myfirstname@osa.pri.ee> - 2019-10-16 07:57 +0300
Re: Which exception for a buffer overrun? Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-16 15:05 +0200
Re: Which exception for a buffer overrun? Keith Thompson <kst-u@mib.org> - 2019-10-16 15:34 -0700
Re: Which exception for a buffer overrun? David Brown <david.brown@hesbynett.no> - 2019-10-16 10:16 +0200
Re: Which exception for a buffer overrun? Öö Tiib <ootiib@hot.ee> - 2019-10-16 05:54 -0700
Re: Which exception for a buffer overrun? David Brown <david.brown@hesbynett.no> - 2019-10-16 16:12 +0200
Re: Which exception for a buffer overrun? Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-16 20:45 +0200
Re: Which exception for a buffer overrun? Öö Tiib <ootiib@hot.ee> - 2019-10-17 06:34 -0700
Re: Which exception for a buffer overrun? David Brown <david.brown@hesbynett.no> - 2019-10-17 16:34 +0200
Re: Which exception for a buffer overrun? Ian Collins <ian-news@hotmail.com> - 2019-10-17 08:15 +1300
Re: Which exception for a buffer overrun? David Brown <david.brown@hesbynett.no> - 2019-10-16 23:00 +0200
Re: Which exception for a buffer overrun? Ian Collins <ian-news@hotmail.com> - 2019-10-17 10:36 +1300
Re: Which exception for a buffer overrun? David Brown <david.brown@hesbynett.no> - 2019-10-17 10:14 +0200
Re: Which exception for a buffer overrun? Daniel <danielaparker@gmail.com> - 2019-10-16 20:06 -0700
Re: Which exception for a buffer overrun? Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-18 09:45 +0200
Re: Which exception for a buffer overrun? Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-17 21:22 +0200
Re: Which exception for a buffer overrun? Paavo Helde <myfirstname@osa.pri.ee> - 2019-10-15 17:48 +0300
Re: Which exception for a buffer overrun? "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2019-10-15 13:09 +0200
Re: Which exception for a buffer overrun? David Brown <david.brown@hesbynett.no> - 2019-10-15 13:35 +0200
Re: Which exception for a buffer overrun? scott@slp53.sl.home (Scott Lurndal) - 2019-10-15 13:30 +0000
Re: Which exception for a buffer overrun? melzzzzz <mel@melzzzzz.com> - 2019-10-15 13:49 +0200
Re: Which exception for a buffer overrun? David Brown <david.brown@hesbynett.no> - 2019-10-15 13:59 +0200
Re: Which exception for a buffer overrun? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-10-15 14:48 +0000
Re: Which exception for a buffer overrun? Paavo Helde <myfirstname@osa.pri.ee> - 2019-10-15 18:37 +0300
Re: Which exception for a buffer overrun? melzzzzz <mel@melzzzzz.com> - 2019-10-15 18:48 +0200
Re: Which exception for a buffer overrun? queequeg@trust.no1 (Queequeg) - 2019-10-16 13:00 +0000
Re: Which exception for a buffer overrun? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-10-15 18:21 +0100
Re: Which exception for a buffer overrun? Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-15 20:32 +0000
Re: Which exception for a buffer overrun? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-10-16 06:20 +0000
Re: Which exception for a buffer overrun? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-10-16 14:43 -0700
Re: Which exception for a buffer overrun? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-10-15 11:12 +0000
Re: Which exception for a buffer overrun? Öö Tiib <ootiib@hot.ee> - 2019-10-15 13:44 -0700
Re: Which exception for a buffer overrun? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-10-15 22:43 +0100
Re: Which exception for a buffer overrun? Öö Tiib <ootiib@hot.ee> - 2019-10-16 00:01 -0700
Re: Which exception for a buffer overrun? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-10-16 19:02 +0000
Re: Which exception for a buffer overrun? Öö Tiib <ootiib@hot.ee> - 2019-10-16 15:22 -0700
Re: Which exception for a buffer overrun? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2019-10-17 03:31 +0100
Re: Which exception for a buffer overrun? Ian Collins <ian-news@hotmail.com> - 2019-10-17 15:35 +1300
Re: Which exception for a buffer overrun? David Brown <david.brown@hesbynett.no> - 2019-10-17 10:17 +0200
Re: Which exception for a buffer overrun? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-10-20 22:18 +0000
Re: Which exception for a buffer overrun? Öö Tiib <ootiib@hot.ee> - 2019-10-21 04:06 -0700
csiph-web