Felix wrote:

>>
>>I'm reluctant to do that from experience with Java's demands that all
>>exceptions be handled. The result was people would just blindly insert
>>catch(...) to shut up the compiler. The result was *worse* because now new
>>exceptions that *needed* to be dealt with got silently swallowed. (I've had
>>some long discussions with well-known Java gurus about this.) It was one of
>>those things that looked great on paper, but failed in practice.

Yes and no.  Being a Java guru, most of the issues resolve around people who
do not know how to work with exceptions.  Think about it.  How many C++ guys
understand exceptions and how to properly handle them, and how many Java guys
understand exceptions and how to properly handle them?

The thing is that the closer to the area of the thrown exception you are, the
better chance you have of working around it.  I actually think that
RuntimeExceptions (AKA unchecked exceptions) can be more damaging to an
application's stability than checked ones.  Will there be newbies that don't
know that catch(Throwable) is bad--I mean really bad?  Of course there will
be.  There will always be new developers who have to learn the hard way. There
will always be lazy developers who don't *want* to learn the proper way.

These developers cause more issues for contienscious developers than anything
else.  Think about it, for some things it is obvious that an exception will be
thrown.  If you are opening a file to read, there is a chance that the file
won't exist.  If it doesn't, and you still try to open it, you *should* expect
a FileNotFoundException, and you should handle it as close to the source of
the problem as possible.  If that file was supposed to be a configuration file,
then we might have to abort the program with another exception.  The exception
is caused by the FileNotFoundException, but the reason the app aborted is a
ConfigNotFoundException or something.

We can get into all kinds of philisophical discussions, but broad sweeping
statements are generally made by people who want to shade the facts toward their
personal point of view.  Could you use a knife to loosen a screw?  Sure, but
I wouldn't advise it.  The point is that there are different tools for different
jobs.  Checked exceptions have their uses--and many times they are an elegant
solution.  Unchecked exceptions also have their uses.

I have seen examples where either type of exception was the wrong tool for the
job.  Saying that it is "a failed experiment" is FUD.  It fails to understand
the problem or the proposed solutions.  What you decide for this language is
up to you--just don't base decisions on broad sweeping statements is all.

Walter wrote:
>>Ok, I can (hopefully) see where you're not understanding our argument.
>>AFAICT no-one's arguing for a C status-quo, which is what all your
> 
> arguments
> 
>>seem to be addressing.
> 
> 
> So, we all agree that C's implicit default:break; is not what we want? (This
> may cause some C code ported to D to have problems crop up. I think this is
> bearable, I just want to make sure it is known.)
> 
> Does this also mean we agree that throwing a runtime exception on the
> default is not a bad thing if it is intended that cases cover all the bases?

I hate to make this more complicated, but ... I very much prefer the default;break; to the default;throw. Sorry! ;)

I could settle for an explicit default requirement, but I don't like the  exception at all. Here's why:

From another one of your posts on this topic:

Walter wrote:
>switch (value)
>> {
>>     case 1:
>>         blah();
>>         break;
>>     case 2:
>>         foo();
>>         break;
>>     case 3:
>>         bar();
>>         break;
>> }
>I view the above switch statement as explicitly saying "the only >possible
>values for value are 1, 2 or 3. No other values are possible. >Therefore, it
>is a program bug if there are any other values."

I don't! Not at all. I believe that's a difference in our coding styles, or maybe the kind of applications we write, but I often use switch in cases where I want the function to do a task X in all cases, but in some cases do tasks A,B or C before that. That translates to a switch statement of the form:

switch(bla)
{
case 1:  doA();
	break;
case 2:  doB();
	break;
case 3:  doC();
	break;
[implicit default;break = do nothing for all other cases]
}

//always executed.
doX();


I performed a search on some of my code and I found that switch statements where I really handle ALL cases are pretty rare. Especially in my networking-related applications there are a lot more switches of the kind I described above.

Compiler software may be different, because, for example, you want to output an error if there is some unexpected token - but this doesn't apply to all kinds of software.

You said you didn't want to force a particular coding style, so please don't force the way switch has to be used!


Hauke

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:br4r11$2tdu$1@digitaldaemon.com...
> I hate to make this more complicated, but ... I very much prefer the default;break; to the default;throw. Sorry! ;)
>
> I could settle for an explicit default requirement, but I don't like the
>   exception at all. Here's why:
>
>  From another one of your posts on this topic:
>
> Walter wrote:
>  >switch (value)
>  >> {
>  >>     case 1:
>  >>         blah();
>  >>         break;
>  >>     case 2:
>  >>         foo();
>  >>         break;
>  >>     case 3:
>  >>         bar();
>  >>         break;
>  >> }
>  >I view the above switch statement as explicitly saying "the only
>possible
>  >values for value are 1, 2 or 3. No other values are possible.
>  >Therefore, it
>  >is a program bug if there are any other values."
>
> I don't! Not at all. I believe that's a difference in our coding styles,

Yes, it's a clear difference in our styles of using switch statements. My experience in code reviews, however, is when there is no explicit default in the switch and I question the programmer about it, it's almost always an oversight (i.e. a bug).

> I performed a search on some of my code and I found that switch statements where I really handle ALL cases are pretty rare.

Mine too, but I like to put in a default:break; to signal to anyone reading the code that I didn't just overlook the other cases!

> You said you didn't want to force a particular coding style, so please don't force the way switch has to be used!

I wish I could please everyone on this, but it's not possible.

"Berin Loritsch" <bloritsch@d-haven.org> wrote in message news:br4q6i$2s7e$1@digitaldaemon.com...
> >>I'm reluctant to do that from experience with Java's demands that all exceptions be handled. The result was people would just blindly insert catch(...) to shut up the compiler. The result was *worse* because now
new
> >>exceptions that *needed* to be dealt with got silently swallowed. (I've
had
> >>some long discussions with well-known Java gurus about this.) It was one
of
> >>those things that looked great on paper, but failed in practice.
>
> Yes and no.  Being a Java guru, most of the issues resolve around people
who
> do not know how to work with exceptions.  Think about it.  How many C++
guys
> understand exceptions and how to properly handle them, and how many Java
guys
> understand exceptions and how to properly handle them?

The Java gurus would tell me that *they themselves* would insert the catch(...)'s, even while publicly preaching against it. They knew all the arguments against doing such, as they came up with those arguments! It wasn't just an issue of ignorant/inexperienced Java coders.

C++ has this problem with "const-correctness". People find themselves stuffing in const keywords and const casts willy-nilly to get the code to compile. (There are even jokes on the internet about this practice.) While the end result will then compile, it isn't exactly "const-correct", little was achieved by it, and I would hazard a guess that few non-trivial C++ programs are actually const-correct because of this.


> We can get into all kinds of philisophical discussions, but broad sweeping statements are generally made by people who want to shade the facts toward
their
> personal point of view.  Could you use a knife to loosen a screw?  Sure,
but
> I wouldn't advise it.  The point is that there are different tools for
different
> jobs.  Checked exceptions have their uses--and many times they are an
elegant
> solution.  Unchecked exceptions also have their uses.
>
> I have seen examples where either type of exception was the wrong tool for
the
> job.  Saying that it is "a failed experiment" is FUD.  It fails to
understand
> the problem or the proposed solutions.  What you decide for this language
is
> up to you--just don't base decisions on broad sweeping statements is all.

While I generally agree with you here, the point I make is that the language should make the right thing to do the easiest thing to do. In Java, the right thing to do with checked exceptions is the most tedious thing to do. The easiest thing to do in Java is just do a catch(...) and forget about it. This is much, much worse than not catching an unexpected unchecked exception (and so letting the runtime eventually handle it). In fact, if I have my Java history right, the whole reason that the Java language eventually added unchecked exceptions at all was the discovery that requiring all exceptions to be checked was unworkable for just the reasons I described.

> > >>I'm reluctant to do that from experience with Java's demands that all exceptions be handled. The result was people would just blindly insert catch(...) to shut up the compiler. The result was *worse* because now
> new
> > >>exceptions that *needed* to be dealt with got silently swallowed.
(I've
> had
> > >>some long discussions with well-known Java gurus about this.) It was
one
> of
> > >>those things that looked great on paper, but failed in practice.
> >
> > Yes and no.  Being a Java guru, most of the issues resolve around people
> who
> > do not know how to work with exceptions.  Think about it.  How many C++
> guys
> > understand exceptions and how to properly handle them, and how many Java
> guys
> > understand exceptions and how to properly handle them?
>
> The Java gurus would tell me that *they themselves* would insert the catch(...)'s, even while publicly preaching against it. They knew all the arguments against doing such, as they came up with those arguments! It wasn't just an issue of ignorant/inexperienced Java coders.
>
> C++ has this problem with "const-correctness". People find themselves stuffing in const keywords and const casts willy-nilly to get the code to compile. (There are even jokes on the internet about this practice.) While the end result will then compile, it isn't exactly "const-correct", little was achieved by it, and I would hazard a guess that few non-trivial C++ programs are actually const-correct because of this.

This is simply wrong. I hear about this from time to time, and it is invariably a lack of care or understanding on the part of the developer. I can't think of a single instance where I've had to violate const-correctness. The few times where I've used const-cast are where it's doing lazy eval, or updating member stats, both of which are perfectly valid.

While your Java exceptions analogy may have some merit, using C++'s const-correctness does not.

"Walter" <walter@digitalmars.com> wrote in message news:br53qk$98m$1@digitaldaemon.com...
>
> "Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:br4r11$2tdu$1@digitaldaemon.com...
> > I hate to make this more complicated, but ... I very much prefer the default;break; to the default;throw. Sorry! ;)
> >
> > I could settle for an explicit default requirement, but I don't like the
> >   exception at all. Here's why:
> >
> >  From another one of your posts on this topic:
> >
> > Walter wrote:
> >  >switch (value)
> >  >> {
> >  >>     case 1:
> >  >>         blah();
> >  >>         break;
> >  >>     case 2:
> >  >>         foo();
> >  >>         break;
> >  >>     case 3:
> >  >>         bar();
> >  >>         break;
> >  >> }
> >  >I view the above switch statement as explicitly saying "the only
> >possible
> >  >values for value are 1, 2 or 3. No other values are possible.
> >  >Therefore, it
> >  >is a program bug if there are any other values."
> >
> > I don't! Not at all. I believe that's a difference in our coding styles,
>
> Yes, it's a clear difference in our styles of using switch statements. My experience in code reviews, however, is when there is no explicit default
in
> the switch and I question the programmer about it, it's almost always an
> oversight (i.e. a bug).

So they should have put in a default, so the compiler should make them do so. QED.

You just keep proving our point.

Here's an article on the topic:

http://www.octopull.demon.co.uk/java/ExceptionalJava.html

Also, I checked Java 1.0. There was a facility for unchecked exceptions in it, so I made a mistake saying it wasn't there. I apologize for the error.

Here's another article:

http://www.mindview.net/Etc/Discussions/CheckedExceptions

Remind me, Walter.  Why don't we have (optional) throws statements?

It seems to me like they would be the best of both worlds - they would allow additional DBC (since 'throws' is essentially an out clause) without requiring people to use kludgy catch(...).

I can imagine that this might be difficult to enforce since the compiler would have to analyze all called functions (unless, of course, they also have 'throws' clauses).  OTOH, you could throw an assertion failure, just like you would when you failed any other out statement.  (Russ ducks flaming arrows headed his way...)

Russ

Walter wrote:
> "Berin Loritsch" <bloritsch@d-haven.org> wrote in message
> news:br4q6i$2s7e$1@digitaldaemon.com...
> 
>>>>I'm reluctant to do that from experience with Java's demands that all
>>>>exceptions be handled. The result was people would just blindly insert
>>>>catch(...) to shut up the compiler. The result was *worse* because now
> 
> new
> 
>>>>exceptions that *needed* to be dealt with got silently swallowed. (I've
> 
> had
> 
>>>>some long discussions with well-known Java gurus about this.) It was one
> 
> of
> 
>>>>those things that looked great on paper, but failed in practice.
>>
>>Yes and no.  Being a Java guru, most of the issues resolve around people
> 
> who
> 
>>do not know how to work with exceptions.  Think about it.  How many C++
> 
> guys
> 
>>understand exceptions and how to properly handle them, and how many Java
> 
> guys
> 
>>understand exceptions and how to properly handle them?
> 
> 
> The Java gurus would tell me that *they themselves* would insert the
> catch(...)'s, even while publicly preaching against it. They knew all the
> arguments against doing such, as they came up with those arguments! It
> wasn't just an issue of ignorant/inexperienced Java coders.
> 
> C++ has this problem with "const-correctness". People find themselves
> stuffing in const keywords and const casts willy-nilly to get the code to
> compile. (There are even jokes on the internet about this practice.) While
> the end result will then compile, it isn't exactly "const-correct", little
> was achieved by it, and I would hazard a guess that few non-trivial C++
> programs are actually const-correct because of this.
> 
> 
> 
>>We can get into all kinds of philisophical discussions, but broad sweeping
>>statements are generally made by people who want to shade the facts toward
> 
> their
> 
>>personal point of view.  Could you use a knife to loosen a screw?  Sure,
> 
> but
> 
>>I wouldn't advise it.  The point is that there are different tools for
> 
> different
> 
>>jobs.  Checked exceptions have their uses--and many times they are an
> 
> elegant
> 
>>solution.  Unchecked exceptions also have their uses.
>>
>>I have seen examples where either type of exception was the wrong tool for
> 
> the
> 
>>job.  Saying that it is "a failed experiment" is FUD.  It fails to
> 
> understand
> 
>>the problem or the proposed solutions.  What you decide for this language
> 
> is
> 
>>up to you--just don't base decisions on broad sweeping statements is all.
> 
> 
> While I generally agree with you here, the point I make is that the language
> should make the right thing to do the easiest thing to do. In Java, the
> right thing to do with checked exceptions is the most tedious thing to do.
> The easiest thing to do in Java is just do a catch(...) and forget about it.
> This is much, much worse than not catching an unexpected unchecked exception
> (and so letting the runtime eventually handle it). In fact, if I have my
> Java history right, the whole reason that the Java language eventually added
> unchecked exceptions at all was the discovery that requiring all exceptions
> to be checked was unworkable for just the reasons I described.

C has an implicit default:break; ?

Regardless, as I don't like your built-in assert(), I certainly don't want the
compiler to add one.

Why do you insist on not breaking ported C code in some cases, while going out of your way to break it in other cases? Make up your mind!

In article <br3sjr$1ajv$2@digitaldaemon.com>, Walter says...
>
>
>"Matthew Wilson" <matthew.hat@stlsoft.dot.org> wrote in message news:bqjr7a$197c$1@digitaldaemon.com...
>> Ok, I can (hopefully) see where you're not understanding our argument. AFAICT no-one's arguing for a C status-quo, which is what all your
>arguments
>> seem to be addressing.
>
>So, we all agree that C's implicit default:break; is not what we want? (This may cause some C code ported to D to have problems crop up. I think this is bearable, I just want to make sure it is known.)
>
>Does this also mean we agree that throwing a runtime exception on the default is not a bad thing if it is intended that cases cover all the bases?
>
>> Put in its simplest form: we want the compiler to
>> force us to write a default, *in all cases*.
>
>If this is our only point of disagreement on this, I don't think it's worthy of all the heat!
>
>> My previous suggestion was to
>> enable the syntactic sugar of substituting "unexpected:" for "default:
>> assert(0);". (Note that "unexpected:" would throw something a little more
>> informative than assert(0), perhaps an UnexpectedCaseException?)
>
>Actually, it throws a SwitchError exception, giving file name and line number.
>
>

Matthew Wilson wrote:

>>>>>I'm reluctant to do that from experience with Java's demands that all
>>>>>exceptions be handled. The result was people would just blindly insert
>>>>>catch(...) to shut up the compiler. The result was *worse* because now
>>
>>
>>The Java gurus would tell me that *they themselves* would insert the
>>catch(...)'s, even while publicly preaching against it. They knew all the
>>arguments against doing such, as they came up with those arguments! It
>>wasn't just an issue of ignorant/inexperienced Java coders.

Maybe it was and they just didn't want to admit it. ;P

Seriously, it isn't so much whether you catch(Exception) (more acceptable
than catch(Throwable)) or not is not the major issue, it is what you do
with it from there.  If you rethrow things you don't intend to worry about
right away, then all is good.

For every one you can claim is doing it wrong even though they know better,
I can point to several more that do it right--without complaint.

>>
>>C++ has this problem with "const-correctness". People find themselves
>>stuffing in const keywords and const casts willy-nilly to get the code to
>>compile. (There are even jokes on the internet about this practice.) While
>>the end result will then compile, it isn't exactly "const-correct", little
>>was achieved by it, and I would hazard a guess that few non-trivial C++
>>programs are actually const-correct because of this.
> 
> 
> This is simply wrong. I hear about this from time to time, and it is
> invariably a lack of care or understanding on the part of the developer. I
> can't think of a single instance where I've had to violate
> const-correctness. The few times where I've used const-cast are where it's
> doing lazy eval, or updating member stats, both of which are perfectly
> valid.
> 
> While your Java exceptions analogy may have some merit, using C++'s
> const-correctness does not.

Again, this is why I call it FUD.  You simply do not know.  For everyone that
is doing it right there are others that do it wrong.  So what to do?  IMO,
make a better mechanism to handle these things.  If you can't learn from
what is out there.

I would prefer to know about potential exceptions if I call a method--esp.
if I can do something about it.  For instance: "Ok this file doesn't exist,
let's use this one as a backup".  Or no config could be loaded so we are
working with defaults.  Whatever.

If a method will throw a known exception I want something stronger than a
comment to tell me about it.

Things that are inadvertant errors such as illegal argument exceptions,
bounds checking exceptions or other obvious runtime exceptions, then I don't
want to know about them or worry about them.  I think having a mix of both
checked and unchecked exceptions provides a nice way to ensure things are
working properly--within reason.

So if you have some system generated exceptions for violations of code
constraints, of course they should be unchecked.

It is quite common for people to filter whatever they hear to fit their
own little world.  For example, if you don't want checked exceptions, ok.
But give solid reasoning beyond so and so said...

Have you worked with a well written system?  Have you worked with a poorly
written system?  What was the *real* problem?  9 times out of 10 is was using
the wrong tool for the job--not that the tool didn't exist.

I brought up C++ exception handling (your catch(...) examples you keep
listing) because I have run into fewer C++ developers who know how to
properly work with exceptions than Java developers.  There are a couple
reasons for this observation.  First is that many C++ developers use C
libraries which force you to do a check on a status bit returned from
a method.  This results in code with a plethora of if(!methodCall()) {}
error handling statements.  The second main reason is that until the last
couple of years there haven't been compilers that produced decent exception
handling code.

Lastly, I will say that I much prefer Java's version of the catchall
statement than C++'s.  Here is the main difference:

C++:

catch(...)
{
   // how do I get the exception, and report info on it?!?
}

Java:

catch(Exception e)
{
    e.printStackTrace();
    System.out.println( e.getClass().getName() );

    // find the root cause
    Throwable cause = e;
    while (e.getCause() != null)
    {
         cause = e.getCause();
    }
}

There are a number of things you can do to have a meaningful error
reported and present the user with a nice message to make it easier
to understand what to do.  Should catch alls be avoided? sure, but I
have seen them more often in C++ code I have had the pleasure of maintaining
than Java....

The bottom line is EVERY language has its weaknesses.  EVERY language
has its strengths.  Somethimes the same thing can be a weekness and
a strength.  It depends on how it is used.  Making blanket statements
is like throwing the baby out with the bath water.