Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #69254

Re: Which exception for a buffer overrun?

Show all headers | View raw

On 16/10/2019 16:12, David Brown wrote:
> On 16/10/2019 14:54, Öö Tiib wrote:
>> On Wednesday, 16 October 2019 11:17:13 UTC+3, David Brown  wrote:
>>> On 15/10/2019 23:59, Soviet_Mario wrote:
>>>> On 15/10/2019 13:57, 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.
>>
>> Basically to live with exceptions all classes have to be RAII as bare
>> minimum. Yes, unique_ptr is one of the handy components for to
>> build (or on simpler case to typedef) such class but I don't
>> understand what readability cost there is.  Can you bring example
>> what you meant?
>>
> 
> I can try and give an outline of an example.  Suppose you have code like
> this, using a bool "success" return instead of exceptions:
> 
> 	bool success = tryThis();
> 	doThisAnyway();
> 	if (!success) return false;
> 	continueProcessing();
> 	return true;
> 
> How do you make that into an exception-based handling, with "tryThis"
> throwing an exception on failure?
> 
> You can use a try block and re-throw:
> 
> 	try {
> 		tryThis();
> 	} catch (...) {
> 		doThisAnyway();
> 		throw();
> 	}
> 	doThisAnyway();
> 	continueProcessing();
> 
> You've duplicated code as well as reducing the clarity.

the example is formally genial :)
But I wonder what could actually be inside.
I mean : a function like dothisanyway should be either 
independent on the execution of tryThis result, or, if it is 
just PARTIALLY dependent, then tryThis seems to have a too 
coarse grain : it has internally a part tryThis depends upon 
and another who don't, and it could be splitted logically in 
two function.
The former who is actually to be put BEFORE doThisAnyway, 
and the latter, possibly generating the error (on which 
doThisAnyway does not depend) who can be placed AFTER IT


getting sth like

tryThisPart_1 ();
doThisAnyway ();
try {
	tryThisPart_2 ();
} catch (...) {
  // etc
};

Part_1 is essential to doThisAnyway
Part_2 is independent

The two Parts seem to me to be logically weakly correlated 
... but it's just sort of an intuition, not really sure


> 
> Or you can make a class:
> 
> 	struct DoThisAnyway_later {
> 		DoThisAnyway_later() {};
> 		~DoThisAnyway_later() { doThisAnyway(); };
> 	}
> 
> 	{
> 		DoThisAnyway_later doThisAnywayLater();
> 		tryThis();
> 		// doThisAnyway called by destructor
> 	}
> 	continueProcessing();
> 
> Now you have re-arranged the order of the code, losing the correlation
> between the textual order and the run-time order.  (A general "scope
> guard" template would reduce the code here, but not change the re-ordering.)
> 
> 
> With explicit, manual control of the errors or unusual circumstances, it
> can be easier to see the flow of the code.
> 
> And note that if you want to be sure that "doThisAnyway()" is done, and
> "tryThis()" does not have a "noexcept" specifier, you have to have
> something like these exception-safe codings just in case, because it
> /might/ throw something.  With a return-based solution, you know if it
> is giving success feedback because it is in the return type (perhaps
> something more sophisticated than a simple bool, such as a
> std::optional, or a variant, or an "expected") - and you can mark it
> with [[nodiscard]] to make sure the code checks the result.
> 
> 
> I am not saying that exceptions /always/ make code harder to read - far
> from it.  I am merely saying that /sometimes/ they do.
> 
> (To be clear here, my kind of C++ programming is usually done with
> exception support disabled in the compiler - partly for worst-case
> 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.)
> 
>>> 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".
>>
>> The exception specifications are often a lie anyway ... or hackable around.
>> What we see in lot of bad code of languages where basically everything
>> may throw? Something like that (Java or C#  code):
>>
>>      public void foo() throws Exception {/* ... */}  // WTF?
>>
>> So there have to be tools and policies in place for to use the exceptions
>> regardless of language. However it is not in any way better with checking
>> error codes of function "success" returns. Latter just adds lot of
>> required boilerplate code. Isn't that major readability cost?
> 
> Somewhere there is /always/ going to be a cost!
> 
> I think a lot of the readability cost of using function return values
> for errors comes from the days of older C and older C compilers, where
> you often had a mess of goto's in order to deal with errors underway
> without having deeply nested "if" statements.  Often you can get a lot
> clearer code by simply dividing the code into several smaller functions,
> with a style of "if (!success) return false;" as an exit.  Before C99
> "inline", and before compilers inlined single-use static functions
> automatically, multiple small functions could quickly be costly in
> efficiency.
> 
> 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.
> 
>>
>>> (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.
>>
>> Every good project has to establish consistent project-wide error
>> handling policy. It is likely possible to make it company-
>> wide when company is working on closely related products
>> in narrow problem domain. However I can not imagine
>> programming-language-wide (or even industry-wide) error
>> handling policies. May be with some different programming
>> language (like Rust).
>>
> 
> Certainly there is no one "ideal for every case" solution here.
> 
>>>
>>>>
>>>> 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.)
>>
>> The errno is awful ... OTOH it seems to be the only semi-portable way
>> in C++ to figure out what went wrong with lot of things (like with that
>> std::basic_fstream::open() and the like) when it matters.
>>
> 
> I am not an errno fan myself.  But I can understand why it was made, and
> that it could be useful for some kinds of coding.
> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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