Re: The D Programming Language
Al wrote:
James Kanze wrote:
<snip>
One of Java's faults is that it doesn't allow you to do anything
reasonable (like crashing) when you've detected the problem.
All you can do is log the error and throw an exception, hoping
that 1) nobody silently swallows the exception (except that
major standard library components do silently swallow
exceptions), and 2) someone reads the log, and notices what went
wrong.
That's an interesting problem that honestly I hadn't considered. I guess
it is kind of creepy to know that whoever is calling you might basically
ignore whatever errors you pop up.
It depends on the type of error. For some types of errors, you
might consider the error more informative: it really is the
callers decision what to do about it, if anything. I ignore
write errors when logging, for example. Other errors are
absolute killers---you don't even know if unwinding the stack is
safe.
On the other hand, from the other point of view (the caller) that's
exactly what is required. It's the very basis of exception safety.
I don't understand this. What is required depends on the
situation. And I don't understand the reference to exception
safety.
Look instead at C++'s throw(). Seems completely bogus to me. Why?
Because in truth, it guarantees absolutely nothing, unlike Java.
I think you've got it backwards. Putting throw() on a function
in Java guarantees pretty much nothing---the function can still
exit via an exception. In C++, it's an absolute guarantee:
you'll never see an exception from that function.
Moreover, I'm not terribly familiar with the Java APIs, but
from a quick search, this showed up:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System.html
Of note is:
static public void System.exit(int);
Which seems to do exactly what you want (i.e., elevate the error all the
way up the hierarchy to make sure it gets paid attention). What more do
you want?
Not quite, but it's pretty close.
Note that it doesn't "elevate the error all the way up the
hierarchy". It terminates the process, immediately. No finally
blocks are executed. About the onlly thing it does that I don't
like (in this case) is run finalizers. And there is apparently
a function Runtime.halt which doesn't even do this, and which is
exactly what I was looking for.
I don't remember these functions from when I was doing Java, but
it's quite possible that I missed them. Halt was only added in
1.3, and the latest version when I was doing was 1.2. It would
seem that Java is trying to address these issues.
Now if only they'd add destructors:-). And allow interfaces to
have non-virtual functions, so you could use programming by
contract, and still have multiple inheritance. (Actually, the
language would be a lot cleaner if they'd just do away with
interfaces, and support multiple inheritance correctly.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]