git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Markus Elfring <Markus.Elfring@web.de>
To: Andreas Ericsson <ae@op5.se>
Cc: Nicolas Pitre <nico@fluxnic.net>, git@vger.kernel.org
Subject: Re: Completion of error handling
Date: Thu, 18 Feb 2010 16:11:03 +0100	[thread overview]
Message-ID: <4B7D5887.6050502@web.de> (raw)
In-Reply-To: <4B7A79F0.1070100@op5.se>


> That's an awful lot of text to read that's hardly relevant for a C
> program. Most of it regards newbie stuff about how to handle reporting
> an error when you can't use a C++ exception.
>   

I would like to quote a bit which shows the underlying issues with the
used programming language.
"...
Exceptional events occur. But, since they are exceptional, they occur
very rarely. This is exactly the problem with them. In programming
courses you learn to always handle any possible event. But, in practice,
most programmers just ignore them. If you look at this problem in
detail, you see that these events are not ignored where they actually
occur, but at some higher level.
..."


>
> You keep on claiming that but haven't proven it in any way.

I do not want to prove this so far because return value ignorance might
be a common and well-known (bad) coding practice.
https://www.securecoding.cert.org/confluence/display/seccode/EXP12-C.+Do+not+ignore+values+returned+by+functions


>
> Git is written in C, not C++. Using aspectc++ would mean requiring
> the use of a C++ compiler, which git doesn't require today.

It would be nice if C++ exceptions could be used here because they can
not be ignored by default. I guess that the tool "AspectC++" will also
work with C constructs. Do you find the tool "AspeCt-oriented C
compiler" more appealing?


> Now please stop trolling and find one of these bugs you keep talking
> about but never showing.

I would not say never. - Exceptional situations are usually expected to
appear seldom.


> We've made it painfully clear to you that we're interested in realworld
> problems rather than potential ones, so all this "use this model for
> development" just reeks of concept evangelism.

The efforts for complete error code checking can be reduced by a mixture
of function, class and advice libraries.


> No real engineer likes that, which is why you're facing
> such massive opposition on this list.
>   

It takes a bit more time to become comfortable with evolving software
technologies.

Regards,
Markus

      reply	other threads:[~2010-02-18 15:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-02 13:11 Completion of error handling Markus Elfring
2010-02-02 18:26 ` Nicolas Pitre
2010-02-02 18:49   ` Markus Elfring
2010-02-02 19:27     ` Nicolas Pitre
2010-02-02 19:42       ` Markus Elfring
2010-02-02 19:49         ` Avery Pennarun
2010-02-02 20:10           ` Markus Elfring
2010-02-02 20:25             ` Avery Pennarun
2010-02-02 21:26               ` Markus Elfring
2010-02-02 21:27                 ` Avery Pennarun
2010-02-02 21:55                   ` Markus Elfring
2010-02-11 13:08   ` Markus Elfring
2010-02-16 10:56     ` Andreas Ericsson
2010-02-18 15:11       ` Markus Elfring [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B7D5887.6050502@web.de \
    --to=markus.elfring@web.de \
    --cc=ae@op5.se \
    --cc=git@vger.kernel.org \
    --cc=nico@fluxnic.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).