Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #69243
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: Which exception for a buffer overrun? |
| Date | 2019-10-16 10:16 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <qo6jls$hog$1@dont-email.me> (permalink) |
| References | <3cf9a0eb-088d-4c7f-903c-d0d40a9e1a8e@googlegroups.com> <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> |
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 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". (Static exceptions will, hopefully, improve on this a lot.) > I mean, often I feel the need of "consistent" (= UNIFORM) error management. Consistency is good - but not if it is artificial consistency just for consistency's sake. > > Even if surely more performant, mixed management can be difficult to > understand and use. > So some importance maybe should also be given to the choice of using the > same tool systematically for every problem of the same nature (errors), > regardeless of its performance potential problems. > Also "snippet" reuse is hindered by mixed use of both exceptions and > return types, and maybe it's more error prone. > > One thing I really can't stand is the way C used to share a single > variable (errno) to store status, that may be overwritten unpredictably > Yes, errno is a very questionable idea. It made sense when it was introduced, but leads to many limitations. It does allow some useful practices, however, such as doing a string of calculations and then checking for errno at the end rather than checking after each calculation. (It's not a single global any more - there is one errno per thread.)
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