Re: why does catching errors that aren't thrown give syntax errors?

blue indigo wrote:
On Sun, 22 Feb 2009 20:13:16 -0500, Arne Vajhøj wrote:
blue indigo wrote:
On Sun, 5654 Sep 1993 12:13:05 +0000, Bent C Dalager wrote:
What, then, /did/ you mean
I meant exactly what I said, mate. Assuming string and character
constants, and maybe one or two other things, are handled correctly, the
only code it would break would be code that was exploiting the non-nesting
of comments to do something "sneaky" like togglable compilation that is
better done using #if and friends.
I gave a very example of a regular comment just placed at
a special location.

You gave an example that was a) contrived and b) broken by the
introduction of C++'s // comments, not by making /* */ comments nest.

It may be contrived.

But it was not broken by C++'s or C99's // comments. In fact it compiles
great in C++ !

But it would break with your proposal.

In practise, I would not expect code like "int a = 2//**/1;" to arise
outside of deliberate obfuscation or, of course, contrived examples.

Neither would I. Among other things because it would not compile
with C++ or a C that has implemented at least that part of C99.

But it is rather irrelevant.

Since it was not the example I gave.

You would gain more credibility in your argumentation, if you
read what you are replying to.

Regardless, I don't think making that change even now would be 1/10 as
horrible as you seem to be making it out to be.
Breaking existing code is always bad.

Breaking existing production code. I hope nothing like "int a = 2//**/1;"
is actually used in production code.

Assuming that we talk about what I wrote - not you invention - then you
never know.

Usually, though, when a project is mission critical everybody sticks with
known-working versions of everything for that project. This is why we have
projects out there that internally use java 1.3 even though java 6 is
current and 7 is around the corner.

It is often postponed for a long time, but eventually an upgrade
often happen.

new HW => new OS version => new C compiler version

Sometimes also, it's a case of no pain, no gain. There must be SOME reason
why they added a method to the javax.sql.Statement interface, as was
lamented in another thread here recently.

Someone considered it a useful feature.

And as demonstrated here people are not happy about it breaking
existing builds.

And this is a case of something that has always been like that. It
is not a new phenomenon.

The bar to justification for a change like any of these is higher the more
production code is likely to be impacted, and the harder it would be to
fix that code.

In the case of javax.sql.Statement I'd say that bar was quite a lot higher
than in the case of either introducing // comments to C or hypothetically
making /* */ comments nest. I'd say introducing // comments to C has the
lower bar, though, and /* */ nesting would be in between,

Given how development of C and Java are progressing and how they are
used, then I would changes to java.sql way under adding nested comments
to C/C++.

// was added to C 10 years ago.

There is a project plan, no hours has been allocated to change anything
in some old code, suddenly if gives build errors, nobody has touched
those X million lines of code for years, first thing is to find someone
that has a clue about how the code works, the project goes directly over
in high risk mode.

See above.

Even if so, sometimes a project needs a kick in the compacency. Legacy
code with no experts around to maintain it will rot your project
eventually anyway. Maybe having to get someone to fix something will save
even worse trouble down the line, like the next y2k crisis in around
twenty years when the number of seconds since the epoch starts to not fit
in a 32-bit integer. The guy might spot a bunch of "int time"s instead of
"long time"s and fix them proactively, or something.

Software are not developed for fun but for money.

Something that must be fixed cost money.

And the chance that it will be used as an opportunity to
cleanup the entire code is pretty small.

Arne
.

Relevant Pages

  • Re: why does catching errors that arent thrown give syntax errors?
    ... projects out there that internally use java 1.3 even though java 6 is ... The bar to justification for a change like any of these is higher the more ... production code is likely to be impacted, and the harder it would be to ... fix that code. ...
    (comp.lang.java.programmer)
  • Re: Norton IS 2005 Breaks Email
    ... Symantec doesn't follow the rules on how to do things and ends up ... > breaking your email connections. ... Only they can fix it but if they ever will ... >> Just when I think I found the offending service, ...
    (microsoft.public.outlook.installation)
  • Re: "Click to activate this control" problem
    ... "Oh, I can fix that. ... Gregg Hill ... "Have any of you actually tried to fix a web site that has ... not have Java installed. ...
    (microsoft.public.frontpage.programming)
  • RE: Some images displayed while others are not .....Help!
    ... I had used system restore to fix ... The only thing I havent done is disable java. ... everything disabled and set at the minimum settings, ... images that will appear on pages while other images on the same page will ...
    (microsoft.public.windows.inetexplorer.ie6.browser)
  • Re: "Click to activate this control" problem
    ... Gregg Hill ... "Oh, I can fix that. ... You said you made the fixes work, now you just say not to use the hover ... not have Java installed. ...
    (microsoft.public.frontpage.programming)