Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #69256
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: Which exception for a buffer overrun? |
| Date | 2019-10-17 08:15 +1300 |
| Message-ID | <h0p8ijF41nU1@mid.individual.net> (permalink) |
| References | (1 earlier) <qo48hb$nfp$1@dont-email.me> <4aaa75f3-a489-49bd-89cf-356ece235d21@googlegroups.com> <qo4c7f$smj$1@dont-email.me> <qo5ffc$fpe$1@dont-email.me> <qo6jls$hog$1@dont-email.me> |
On 16/10/2019 21:16, David Brown wrote: > On 15/10/2019 23:59, Soviet_Mario wrote: >> On 15/10/2019 13:57, David Brown wrote: >>> On 15/10/2019 13:08, Frederick Gotham wrote: >>>> On Tuesday, October 15, 2019 at 11:54:45 AM UTC+1, Paavo Helde >>>> wrote: >>>> >>>>> A buffer overrun should be considered a bug in the program and >>>>> should be dealt with by abort() or similar, not by an exception. >>>> >>>> >>>> So if I use a scissors to cut a slice of bread, am I abusing the >>>> scissors? >>> >>> I'd say yes. Aim to use the right tool for the job. Use a poorer >>> choice of tool if you can't get the right tool, but only if there is no >>> option. >>> >>> <https://www.youtube.com/watch?v=B84pS6JTI9A> >>> >>>> >>>> Are you one of those people who will only use something for the one >>>> specific use that it says on the box? >>> >>> I can't answer for Paavo, but I am one of these people who try to think >>> out the best way to handle a task. >>> >>>> >>>> I'm curious what your stance is on exception throwing in recursive >>>> functions (instead of conditional return statements)? >>>> >>> >>> In C++, throwing an exception is usually /massively/ slower than >>> returning a code. It can easily be thousands of times slower. And for >>> recursive functions, it probably scales in time with the depth of the >>> recursion - and may limit optimisations of the functions. >>> >>> Exceptions are fine when the situation is very rare and you don't have >>> requirements for worst-case latency, or where there is no sensible way >>> to handle the situation (like running out of memory), or when efficiency >>> doesn't matter and they make the code simpler and clearer (perhaps for >>> network or file errors). >>> >>> They are a bad idea for normal processing as an alternative to return >>> values. >>> >>> (The balance here will change significantly once static exceptions are >>> part of the language - they will be a great deal more efficient, and a >>> great deal easier for compile-time checking to support, at the cost of >>> less flexibility). >>> >> >> >> mine is just a no more than a hobbist tinkerer's opinion, but ... >> even if I surely won't object to performance issues, another (often >> contrasting) point of view would be readability and cross-usability of code >> > > 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. > 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. -- Ian.
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