Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: c is unfinished |
| Date | 2016-03-16 22:40 +1300 |
| Message-ID | <dksnvqFm4ihU2@mid.individual.net> (permalink) |
| References | (13 earlier) <nc7fl0$sd$1@dont-email.me> <dc392ce6-27c3-458a-9912-e364e0ed95df@googlegroups.com> <nc8iqs$v8s$1@dont-email.me> <dksgtjFm4ihU1@mid.individual.net> <ncb4f7$otm$1@dont-email.me> |
On 03/16/16 21:14, David Brown wrote: > On 16/03/16 08:39, Ian Collins wrote: >> On 03/15/16 22:01, David Brown wrote: >> >>> >>> Exceptions have their disadvantages too. Combined with good RAII, they >>> may save you from remembering to clean up some resources along the way - >>> but they don't stop you forgetting to handle the exception. So that >>> means that any seemingly safe function call, that would not need any >>> error checking in C, might return half-completed with an exception. >> >> I don't see how this would happen - if something throws it should have >> an equivalent check in C. >> >>> I am not convinced that exceptions really help - they just move the >>> problem around a bit. (RAII, of course, is a great idea.) >> >> I think you have spent too long in the embedded world David! The number >> of times I wish I had a "bugger it, give up!" option in C isn't small.. >> >>> In my view, C++ exceptions would be much more useful if they really were >>> for exceptional circumstances. The key problems with C-style error >>> handling (when using C++ with RAII) are: >> >> Yes, I can see that, but those horses have bolted. >> >>> 1. You have to remember to check for errors from any function that can >>> return errors. >>> 2. This error checking must be done at the point of the function call. >>> 3. The error checking has overhead, whether there is an error or not. >>> 4. Whether a function can return an error or not is a matter of >>> documentation for the function, and not something the compiler can check. >>> >>> The key problems with C++ exceptions, as I see it: >>> >>> 1. You have to remember to handle exceptions from any function that can >>> throw an exception. >> >> There's the think - you don't. You can choose to deffer the handling at >> a place where its makes most sense. If you have a complex transaction >> that doesn't support retries, you may as well just catch at the level of >> the top level call. or even in main if a condition isn't recoverable. > > No, you /do/ need to remember to handle exceptions from any function > that can throw an exception. You might want to handle it in a different > place, further up the call chain, but you still need to handle it. Indeed, but the choice is yours. If you miss an error code check, you may never know... > And > the further you are from the point of the throw, the bigger the risk > that you will forget (or that someone else is writing that code, and you > have not communicated the exception requirements well enough). But even then, if an exception is thrown, you will know. Missing error codes is a silent bug. <snip> >>> In other words, C++ exceptions don't solve the issues with C error >>> handling. They just move it around a bit, and hide some of it. >> >> Hide a lot of it! > > Some (including me) would say that they hide the issues too much - you > want to know about possible errors and handle them. Often, you don't. There could a be a dozen ways for a transaction to fail, but all the calling code cares about is did it fail or not? If needed, the exception can covey the detail. >>> If a function wants to throw, it has to have a "throw" specifier listing >>> the exception classes that it can throw. It is allowed to throw those >>> classes, or classes derived from them - and nothing else. The stdexcept >>> class hierarchy would be extended to make this convenient - typically >>> all exception classes would derive ultimately from a common base class. >> >> Haven't other languages tried this and ended up with either a terrible >> mess, or all exceptions derived form a common base? >> > > Some OO languages use common bases for object hierarchies - sometimes it > is a good thing, sometimes a bad thing. I suggest it here as a better > way of having a "catch anything" clause - but it is not a key point in > my suggested solution. I was thinking more of the case of "Bloody hell! do we have to list all these exceptions in the function declaration? Bugger it, make them inherit from a common base". Which ends up being worse than useless. -- Ian Collins
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
c is unfinished fir <profesor.fir@gmail.com> - 2016-03-13 12:52 -0700
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-13 13:05 -0700
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-13 13:25 -0700
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-13 16:28 -0700
Re: c is unfinished Les Cargill <lcargill99@comcast.com> - 2016-03-13 15:20 -0500
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-13 13:15 -0700
Re: c is unfinished Les Cargill <lcargill99@comcast.com> - 2016-03-14 07:27 -0500
Re: c is unfinished gazelle@shell.xmission.com (Kenny McCormack) - 2016-03-14 12:47 +0000
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 06:50 -0700
Re: c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-14 07:04 -0700
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 07:23 -0700
c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-13 14:17 -0700
Re: c is unfinished "John M. Harris, Jr." <johnmh@openblox.org> - 2016-03-14 08:57 -0400
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 07:06 -0700
Re: c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-14 07:23 -0700
Re: c is unfinished "John M. Harris, Jr." <johnmh@openblox.org> - 2016-03-14 10:28 -0400
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 08:06 -0700
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 15:26 +0000
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 08:38 -0700
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 09:15 -0700
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 09:42 -0700
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 16:23 +0000
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 09:56 -0700
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 10:03 -0700
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 17:28 +0000
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 11:08 -0700
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 18:51 +0000
Re: c is unfinished raltbos@xs4all.nl (Richard Bos) - 2016-03-14 22:10 +0000
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 16:26 -0700
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 23:55 +0000
Re: c is unfinished supercat@casperkitty.com - 2016-03-14 22:44 -0700
Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-15 08:59 +0100
Re: c is unfinished supercat@casperkitty.com - 2016-03-15 07:23 -0700
Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-15 15:31 +0100
Re: c is unfinished supercat@casperkitty.com - 2016-03-15 08:02 -0700
Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-16 08:11 +0100
Re: c is unfinished supercat@casperkitty.com - 2016-03-16 08:33 -0700
Re: c is unfinished Ian Collins <ian-news@hotmail.com> - 2016-03-15 09:40 +1300
Re: c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-14 14:01 -0700
Re: c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-14 15:33 -0700
Re: c is unfinished gazelle@shell.xmission.com (Kenny McCormack) - 2016-03-14 23:07 +0000
Re: c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-14 16:27 -0700
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 19:37 -0700
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 21:07 +0000
Re: c is unfinished Ian Collins <ian-news@hotmail.com> - 2016-03-15 10:16 +1300
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 22:05 +0000
Re: c is unfinished Öö Tiib <ootiib@hot.ee> - 2016-03-14 15:30 -0700
Re: c is unfinished supercat@casperkitty.com - 2016-03-14 15:39 -0700
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 23:00 +0000
Re: c is unfinished Öö Tiib <ootiib@hot.ee> - 2016-03-14 18:09 -0700
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-15 08:14 +0000
Re: c is unfinished Öö Tiib <ootiib@hot.ee> - 2016-03-15 13:51 -0700
Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-15 10:01 +0100
Re: c is unfinished Öö Tiib <ootiib@hot.ee> - 2016-03-15 17:07 -0700
Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-16 08:26 +0100
Re: c is unfinished Öö Tiib <ootiib@hot.ee> - 2016-03-16 13:28 -0700
Re: c is unfinished Philip Lantz <prl@canterey.us> - 2016-03-15 20:03 -0700
Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-16 08:52 +0100
Re: c is unfinished Ian Collins <ian-news@hotmail.com> - 2016-03-16 20:39 +1300
Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-16 09:14 +0100
Re: c is unfinished Ian Collins <ian-news@hotmail.com> - 2016-03-16 22:40 +1300
Re: c is unfinished David Brown <david.brown@hesbynett.no> - 2016-03-16 12:46 +0100
Re: c is unfinished Ian Collins <ian-news@hotmail.com> - 2016-03-15 14:53 +1300
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-15 08:17 +0000
Re: c is unfinished Ian Collins <ian-news@hotmail.com> - 2016-03-15 21:19 +1300
Re: c is unfinished Öö Tiib <ootiib@hot.ee> - 2016-03-14 15:16 -0700
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 19:03 -0700
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 08:32 -0700
Re: c is unfinished Keith Thompson <kst-u@mib.org> - 2016-03-14 08:43 -0700
Re: c is unfinished Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-14 16:14 +0000
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 10:01 -0700
Re: c is unfinished Richard Heathfield <rjh@cpax.org.uk> - 2016-03-14 17:30 +0000
Re: c is unfinished Keith Thompson <kst-u@mib.org> - 2016-03-14 10:57 -0700
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 11:32 -0700
Re: c is unfinished Keith Thompson <kst-u@mib.org> - 2016-03-14 12:12 -0700
Re: c is unfinished Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-14 19:21 +0000
Re: c is unfinished raltbos@xs4all.nl (Richard Bos) - 2016-03-14 22:16 +0000
Re: c is unfinished supercat@casperkitty.com - 2016-03-14 15:34 -0700
Re: c is unfinished Robert Wessel <robertwessel2@yahoo.com> - 2016-03-14 20:15 -0500
Re: c is unfinished supercat@casperkitty.com - 2016-03-14 22:05 -0700
Re: c is unfinished Keith Thompson <kst-u@mib.org> - 2016-03-14 22:34 -0700
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 16:17 -0700
Re: c is unfinished Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-15 01:10 +0000
Re: c is unfinished supercat@casperkitty.com - 2016-03-14 12:03 -0700
Re: c is unfinished Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-14 19:08 +0000
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 13:01 -0700
Re: c is unfinished supercat@casperkitty.com - 2016-03-14 13:28 -0700
Re: c is unfinished Keith Thompson <kst-u@mib.org> - 2016-03-14 14:25 -0700
Re: c is unfinished supercat@casperkitty.com - 2016-03-14 14:40 -0700
Re: c is unfinished Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-03-14 14:44 -0700
Re: c is unfinished raltbos@xs4all.nl (Richard Bos) - 2016-03-14 22:44 +0000
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-14 19:26 -0700
Re: c is unfinished "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-03-14 07:09 -0700
Re: c is unfinished Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2016-03-13 23:34 +0000
Re: c is unfinished fir <profesor.fir@gmail.com> - 2016-03-13 16:40 -0700
Re: c is unfinished supercat@casperkitty.com - 2016-03-14 09:33 -0700
csiph-web