> So, I see the taxonomy as being either (now using my/Ben's names):
>
> Object <= not throwable, btw
> Throwable
> Error <= Unrecoverable exceptions
> ContractViolation
> Assertion
> Exception
> FileNotFoundException
> XMLParseException
> Exhaustion
> MemoryExhaustion
> TSSKeyExhaustion
Why shouldn't Object be throwable? It has useful methods like toString() and
print() (I'm starting to think print() should stay). What would Throwable
provide that Object doesn't? I would make it harder to throw the wrong thing
I suppose:
throw new Studebacker()
OutOfMemory is special because in typical usage if you run out of memory you
can't even allocate another exception safely. Memory is the one resource
programs have a very very hard time running without. It must be catchable
because otherwise there's no way to tell if a large allocation failed or
not. Running out of threads is much less catastrophic than running out of
memory.
Similarly I would treat assertion failures as more catastrophic than other
exceptions. But as I indicated in my original post I believe there is no
such thing as an unrecoverable (but catchable) error/exception.
>>>>> (And the language
>>>>> should mandate and enforce the irrecoverability.)
>>>>
>>>> Disagree.
>>>
>>> For reasons so blindingly obvious/insightful that you needn't
>>> specify them, I guess.
>>
>> Sarcasm is the lowest form of wit.
>
> Maybe so, but unstubstantiated opinion is worth precisely nothing. It's an
> inconsiderate waste of other people's time.
>
>> Why do you need to force a program to terminate? If the programmer wants
>> to continue and can do so, they will, if not, they wont. I see no need to
>> enforce it.
>
> There are several flaws suggested in your understanding of the issue by
> just those two sentences.
<sarcasm>
Windows used to have this feature where if you tried hard enough the screen
would go blue. It was called the "blue screen of death" because some people
died of joy when they saw it. Fearing lawsuits, though, Microsoft had to
remove the feature, much to the dismay of Windows users worldwide.
</sarcasm>

"xs0" <xs0@xs0.com> wrote in message
news:d3g5os$27cj$1@digitaldaemon.com...
> Not that I disagree, in principle, but there are still cases where
> you'd want to recover from an "unrecoverable" error. Consider an
> environment like Eclipse, which is built totally out of plugins,
> and there can be hundreds of them. What you're saying is that
> whenever one of those faults, the whole system should abort, which
> is definitely not what I'd want it to do.
With respect - I'm going to use "with respect" a lot in this thread,
and I'm going to mean it, because I fear I am going to
insult/patronise - I think you miss the point. It's easy to do, of
course, since this irrecoverability is challenging stuff: when I
read this paragraph I thought, "ah yes, that is an exception". But
of course it's not, nor are any of the many other examples I've been
given over the last year or so to counter the principle.
1. As soon as your editor encounters a CP violation, it is, in
principle and in practice, capable of doing anything, including
using your work. The only justifiable action, once you've saved (if
possible) and shut down, is to disable the offending plug-in. (I
know this because I use an old version of Visual Studio. <G>)
2. The picture you've painted fails to take into account the effect
of the extremely high-intolerance of bugs in "irrecovering code".
Basically, they're blasted out of existence in an extremely short
amount of time - the code doesn't violate its design, or it doesn't
get used. period - and the result is high-quality systems.
> I mean, when I do something like inspect a value in a debugger,
> and the value is 150MB and the debugger runs out of memory, I
> don't want it to stop, just because it can't show me a var (which
> can just as easily manifest as an assertion error or whatever)...
Out of memory is not an error, it's an exception, so that's just not
an issue.
btw, at no time have I _ever_ said that processes should just stop.
There should always be some degree of logging of the flaw and, where
appropriate, an attempt made to shutdown gracefully and with as
little collateral damage as possible.
> Enforcing unrecoverability would be a mistake, if you ask me,
> although I totally support an exception hierarchy that would make
> "unrecoverable" errors something people wouldn't try to catch
> normally.
I don't understand the second half of that sentence, so let's deal
with the first. You say enforcing irrecoverability would be a
mistake, but don't suggest any reason. Therefore I must assume
reasons based on previous parts of the post, which I've shown are
either not taking into account the principles of invalid software,
or appear to mistake runtime exceptions for contract violations.
So, given that:
- irrecoverability applies only to contract violations, i.e.
code that is detected to have violated its design via runtime
constructs inserted by its author(s) for that purpose
- an invalid process cannot, by definition, perform validly. It
can only stop, or perform against its design.
- "Crashing Early" in practice results in extremely high quality
code, and rapid turn around of bug diagnosis and fixes
- D cannot support opt-in/library-based irrecoverability; to
have it, it must be built in
do you still think it would be a mistake?
If so, can you explain why?

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
news:d3gff9$2gvc$1@digitaldaemon.com...
>
>> So, I see the taxonomy as being either (now using my/Ben's
>> names):
>>
>> Object <= not throwable, btw
>> Throwable
>> Error <= Unrecoverable exceptions
>> ContractViolation
>> Assertion
>> Exception
>> FileNotFoundException
>> XMLParseException
>> Exhaustion
>> MemoryExhaustion
>> TSSKeyExhaustion
>
> Why shouldn't Object be throwable? It has useful methods like
> toString() and print() (I'm starting to think print() should
> stay). What would Throwable provide that Object doesn't? I would
> make it harder to throw the wrong thing I suppose:
> throw new Studebacker()
Exactly that. Is that not adequate motivation?
> OutOfMemory is special because in typical usage if you run out of
> memory you can't even allocate another exception safely.
Indeed, although that's easily obviated by having the exception
ready, on a thread-specific basis. (I'm sure you know this Ben, but
it's worth saying for purposes of general edification.)
> Memory is the one resource programs have a very very hard time
> running without.
"the one"? Surely not. I've already mentioned TSS keys. They're at
least as hard to live without. And what about stack? (Assuming you
mean heap, as I did.)
> It must be catchable because otherwise there's no way to tell if a
> large allocation failed or not.
Well, no-one's debating whether or not that, or any other
error/exception, is catchable. (It's worrying me that there are now
two people talking about catchability, as if the possibility of
uncatchability has been raised.)
> Running out of threads is much less catastrophic than running out
> of memory.
I agree, but who's talked about threads? I mentioned TSS keys, but
they're not the same thing at all. Maybe someone else has discussed
threads, and I've missed it.
> Similarly I would treat assertion failures as more catastrophic
> than other exceptions.
Naturally. They're terminal.
> But as I indicated in my original post I believe there is no such
> thing as an unrecoverable (but catchable) error/exception.
Do you mean you believe there is no such thing in D now? If so,
you're quite right.
Do you mean that you believe there will never be such a thing in D?
If so, I think you're likely to be proved right.
Do you mean there's no such thing as an irrecoverable exception
_anywhere_? If so, you're wrong. I've written, and make good use of,
one in C++
Do you mean you don't believe there is a motivating case for
irrecoverability? If so, can you explain why, address the points
I've just made to xs0:
- irrecoverability applies only to contract violations, i.e.
code that is detected to have violated its design via runtime
constructs inserted by its author(s) for that purpose
- an invalid process cannot, by definition, perform validly.
It
can only stop, or perform against its design.
- "Crashing Early" in practice results in extremely high
quality
code, and rapid turn around of bug diagnosis and fixes
- D cannot support opt-in/library-based irrecoverability; to
have it, it must be built in
Specifically, I'm intrigued to hear of a case that shows
irrecoverability to be a bad idea (excepting debugging of course,
which I've already recognised).
> <sarcasm>
> Windows used to have this feature where if you tried hard enough
> the screen would go blue. It was called the "blue screen of death"
> because some people died of joy when they saw it. Fearing
> lawsuits, though, Microsoft had to remove the feature, much to the
> dismay of Windows users worldwide.
> </sarcasm>
But I fear this is what people, through ignorance or laziness or
whatever, are portraying the irrecoverability / "Crashing Early"
debate to be, and it's quite disingenuous. Although there can be no
guarantees in what's supportable behaviour after a contract
violation occurs, practically speaking there's always scope for
creating a log to screen/file, and often for saving current work (in
GUI contexts).
Since I've had nothing but marked success using the technique over
the last year, and it's lauded by people such as The Pragmatic
Programmers, I'd be very interested to hear from anyone who has a
negative experience using it. Otherwise, if there's nothing but
unsubstantiated opinion on one side, versus positive supportive
evidentiary experience on the other, it's kind of pointless trying
to have a balanced debate, don't you think?
Matthew

Regan Heath wrote:
> On Tue, 12 Apr 2005 15:16:55 +1000, Matthew
> <admin@stlsoft.dot.dot.dot.dot.org> wrote:
>
>> "Regan Heath" <regan@netwin.co.nz> wrote in message
>> news:opso3kiga523k2f5@nrage.netwin.co.nz...
>>
>>> On Mon, 11 Apr 2005 21:01:40 -0400, Ben Hinkle
>>> <ben.hinkle@gmail.com> wrote:
>>>
>>>>>> The distinction in Java is poorly designed and can be
>>>>>> covered in D by subclassing Object directly.
>>>>>
>>>>> So if you want an un-recoverable error you subclass object
>>>>> and never catch Object directly?
>>>>
>>>> What do you have in mind as a user-defined unrecoverable error?
>>>
>>> Nothing new, I was looking at: OutOfMemory AssertionFailure
>>>
>>> and thought, for most applications these are treated as
>>> unrecoverable errors.
>>
>> They may be, but that's quite wrong.
>>
>> OutOfMemory is practically unrecoverable, but should not be classed
>> as an unrecoverable exception.
I want to allocate memory. I could first check if there is enough, but
since I'm on a Real Operating system, there are other users, who also
may allocate memory between my check and my actual allocating.
I let my program allocate, and if it runs out of memory, it then
deallocates some, and tries to get by with what it got.
Another scenario: In 1982 I bought my first computer. It wrote "ready"
as the prompt, and you could do arithmetic right on the command line. I
remember the first time "it spoke to me": I was trying out increasingly
more complicated functions, and suddenly it wrote "formula too complex".
Man, I sat quiet for a good while, staring in awe at the unbelievable
intelligence of a piece of silicon.
Now I know the interpreter had run out of stack space. But instead of
crashing, it recovered gracefully.
Trying to load a too big picture or movie in an editing program should
not terminate the program. It should inform you, and then let you choose
some other file.
---------
In general, I think the responsibility to have the program terminated,
should lie on the particular piece of code that first becomes aware of
the unrecoverability of a situation.
Typically, a server program should terminate if it can't open the log
file. A filter program should terminate if it can't open stdout. A
hd-formatter should terminate if there is no hd. But there are no hard
rules like "can't open file, so terminate".
But the "recognition of a terminate situation" may not always be at the
first site of "error detection". It may just as well be several
throw/catches up in the call stack.
An example would be a routine that can't do something. It throws an
exception, and somewhere higher up there's another routine that knows
that this exception in these circumstances means we got an unrecoverable
situation.
And then _that_ piece of code throws an uncatchable.
--------
Many languages offer programmers the ability to write program termiation
handlers. These are usually for situations where the program has to do
some unusual tidying up before actual termination. In Real Operating
systems the programmer can additionally catch _any_ signal (except the
one uncatchable "shot in the neck") that would normally lead to program
termination, and do things he pleases instead.
Ultimately we (as language and compiler people) should let the
programmer decide what to do, and not force a particular chain of events
upon him.
That said, the Error/Exception hierarchy, combined with
throw/catch/finally is there to help the programmer sort out this mess.
To make this possible, the libraries should give a good and solid
foundation for doing this. But nothing more.
----------
Done right, this means that most not-hoped-for situations and events
throw something. This need not necessarily be caught at the next level,
if that level wouldn't know what to do with it. And if it is not caught
even in main(), then the runtime should terminate the program (of course
displaying the reason).
The programmer may do catch-alls (if he is lazy/stupid), and it is not
for us to prevent this.
On the other hand, there should exist non-catchable throwables. These
are for situations where the code (be it library code, or top level
user-code, or whatever) notices we have to terminate.
An example would be a program that operates a robot arm. Certain
combinations of inputs from the robot arm sensors may denote an
unacceptable or unhandlable condition. The piece of code that notices
this should throw an uncatchable error. (Lame example, but "it's the
thought that counts". :-) )
Whether we intend to use non catchable exceptions, should not prevent us
from incorporating them in the hierarchy. We should have both.
-------------
The _sole_ point of having a hierarchy is to let catch clauses catch
several different kinds of errors at a time. (For example, someone might
want to catch all file errors.)
A good hierarchy has this as its main goal.
In other words, it is not sufficient to just classify errors "in a
logical way". What is needed is diligent study of how and when such
errors might be thrown and caught, and how this could be made as simple
and natural as possible to use in the user code.
-------------
Personally I think the language need not define more than two
throwables: Error and Exception. The former being uncatchable, and the
latter being catchable.
The runtime and standard libraries can then define the hierarchy as they
want. I'd like the hierarchy to be of tight granularity (a big and thick
tree). This would make it convenient and natural for the programmer to
actually get in the habit of using exceptions, catching precisely what
is needed, and gradually start creating his own exceptions.
> Agreed, in part, why "class" it as anything but what it is?
>
>> Conversely, AssertionFailure is practically recoverable, but most
>> certainly should be classed as unrecoverable.
>
> As above, why "class" it as anything but what it is?
>
>> (And the language should mandate and enforce the irrecoverability.)
>
> Disagree.

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3ggkh$2i42$1@digitaldaemon.com...
>
> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
> news:d3gff9$2gvc$1@digitaldaemon.com...
>>
>>> So, I see the taxonomy as being either (now using my/Ben's names):
>>>
>>> Object <= not throwable, btw
>>> Throwable
>>> Error <= Unrecoverable exceptions
>>> ContractViolation
>>> Assertion
>>> Exception
>>> FileNotFoundException
>>> XMLParseException
>>> Exhaustion
>>> MemoryExhaustion
>>> TSSKeyExhaustion
>>
>> Why shouldn't Object be throwable? It has useful methods like toString()
>> and print() (I'm starting to think print() should stay). What would
>> Throwable provide that Object doesn't? I would make it harder to throw
>> the wrong thing I suppose:
>> throw new Studebacker()
>
> Exactly that. Is that not adequate motivation?
Not to me - but then I haven't seen much newbie code involving exception
handling.
>> OutOfMemory is special because in typical usage if you run out of memory
>> you can't even allocate another exception safely.
>
> Indeed, although that's easily obviated by having the exception ready, on
> a thread-specific basis. (I'm sure you know this Ben, but it's worth
> saying for purposes of general edification.)
Easily? Preallocating exceptions or other objects in case an OutOfMemory is
thrown is an advanced maneuver IMO.
>> Memory is the one resource programs have a very very hard time running
>> without.
>
> "the one"? Surely not. I've already mentioned TSS keys. They're at least
> as hard to live without. And what about stack? (Assuming you mean heap, as
> I did.)
I view running out of TSS keys as running out of gas in a car - a pain but
expected. I view running out of memory as running out of oxygen in the
atmosphere - a bigger pain and unexpected.
>> It must be catchable because otherwise there's no way to tell if a large
>> allocation failed or not.
>
> Well, no-one's debating whether or not that, or any other error/exception,
> is catchable. (It's worrying me that there are now two people talking
> about catchability, as if the possibility of uncatchability has been
> raised.)
yup - I just wanted to be clear.
>> Running out of threads is much less catastrophic than running out of
>> memory.
>
> I agree, but who's talked about threads? I mentioned TSS keys, but they're
> not the same thing at all. Maybe someone else has discussed threads, and
> I've missed it.
TSS means "thread-specific storage", correct? I was guessing that was what
it meant but maybe I was wrong. Personally
>> Similarly I would treat assertion failures as more catastrophic than
>> other exceptions.
>
> Naturally. They're terminal.
>> But as I indicated in my original post I believe there is no such thing
>> as an unrecoverable (but catchable) error/exception.
>
> Do you mean you believe there is no such thing in D now? If so, you're
> quite right.
>
> Do you mean that you believe there will never be such a thing in D? If so,
> I think you're likely to be proved right.
>
> Do you mean there's no such thing as an irrecoverable exception
> _anywhere_? If so, you're wrong. I've written, and make good use of, one
> in C++
>
> Do you mean you don't believe there is a motivating case for
> irrecoverability? If so, can you explain why, address the points I've just
> made to xs0:
>
> - irrecoverability applies only to contract violations, i.e.
> code that is detected to have violated its design via runtime
> constructs inserted by its author(s) for that purpose
> - an invalid process cannot, by definition, perform validly. It
> can only stop, or perform against its design.
> - "Crashing Early" in practice results in extremely high quality
> code, and rapid turn around of bug diagnosis and fixes
> - D cannot support opt-in/library-based irrecoverability; to
> have it, it must be built in
>
> Specifically, I'm intrigued to hear of a case that shows irrecoverability
> to be a bad idea (excepting debugging of course, which I've already
> recognised).
>
>> <sarcasm>
>> Windows used to have this feature where if you tried hard enough the
>> screen would go blue. It was called the "blue screen of death" because
>> some people died of joy when they saw it. Fearing lawsuits, though,
>> Microsoft had to remove the feature, much to the dismay of Windows users
>> worldwide.
>> </sarcasm>
>
> But I fear this is what people, through ignorance or laziness or whatever,
> are portraying the irrecoverability / "Crashing Early" debate to be, and
> it's quite disingenuous. Although there can be no guarantees in what's
> supportable behaviour after a contract violation occurs, practically
> speaking there's always scope for creating a log to screen/file, and often
> for saving current work (in GUI contexts).
Let me give another example besides BSOD why "unrecoverable" is
application-specific. Let's say I'm writing an application like Photoshop or
GIMP (or, say, MATLAB) that has a concept of plug-ins. Now if a plug-in
asserts and gets itself into a bad state the controlling application must be
able to catch that and recover. Any decent application would print out some
message like "the plugin Foo had an internal error and has been unloaded"
and unload the offending plug-in. It would be unacceptable for the
language/run-time to force the controlling application to quit because of a
faulty plug-in. In the same way modern OSes don't quit when an application
has an internal error.

In article <d3g2ho$2477$1@digitaldaemon.com>, Matthew says...
>
>But, as I said in a previous post, I think the jury's still out on
>OutOfMemory. I've a strong suspicion it should fall out as being an
>exception, but I think there's some mileage in discussing whether it
>might have another 'type', e.g. ResourceExhaustion. Reason being
>that, though memory exhaustion is in principle recoverable, in
>practice it is not recoverable (since getting memory to throw/handle
>is tricky, and may require workarounds) and also often so unlikely
>as to make it not worth worrying about.
Tricky perhaps, but that's why this sort of thing is taken care of by a standard
library. This should already work in Phobos (there's a static OutOfMemory
exception somewhere IIRC), and I was considering creating an OutOfMemoryError
per thread in Ares, though that's an issue that likely warrants GC discussion to
see if it's necessary.
>So, I see the taxonomy as being either (now using my/Ben's names):
>
>Object <= not throwable, btw
This would be nice, but it's quite obviously a language issue, not a runtime
issue. So Walter will have to chime in here.
> Throwable
> Error <= Unrecoverable exceptions
> ContractViolation
> Assertion
> Exception
> FileNotFoundException
> XMLParseException
> Exhaustion
> MemoryExhaustion
> TSSKeyExhaustion
>
>or, if we just lump exhaustions in with exceptions
>
>Object <= not throwable, btw
> Throwable
> Error <= Unrecoverable exceptions
> ContractViolation
> Assertion
> Exception
> FileNotFoundException
> XMLParseException
> MemoryExhaustionException
> TSSKeyExhaustionException
I kind of like the first method only because exhaustion errors tend to need
special handling and I'm not sure I like that they can be ignored simply by
catching an Exception object. Then again, if there's still no memory available
when handing an OutOfMemory error then another OutOfMemory error will be thrown,
so there's little danger in ending up in an invalid state.
>First, "Why do you need to force a program to terminate?". This
>one's simple: The program must be forced to terminate because it has
>violated its design. (Let me digress for a moment and confess that
>before I made the leap into CP-grok-ville this never seemed simple,
>or at least never cut and dried.)
I agree. Frankly, preventing application failure on contract violation is as
simple as compiling without DBC anyway. I don't like the idea of being able to
situationally handle contract violations by catching AssertError.
>Notwithstanding all the foregoing, there's a much more fundamental,
>albeit little recognised, issue. Computers make a strict
>interpretation of what we, the programmers, instruct them to do. Now
>a contract violation, as I've said, is pure and simple a statement
>that your instructions to the computer (or to the compiler, if you
>will) are fundamentally flawed. Since computers do not have
>redundancy, intuition, instincts, sixth-sense, a friend to call, or
>any other "higher order" functioning, there are exactly two things a
>process can do in that circumstance. It can operate in a
>fundamentally flawed manner, or it can stop. THERE ARE NO OTHER
>OPTIONS.
It would be an interesting feature of a programming language to have a support
staff that it consults in the event of unexpected errors. Perhaps the next
iterationasic could have this feature? (sorry, the mental image was just too
entertaining to pass up)
Sean

Matthew wrote:
> "xs0" <xs0@xs0.com> wrote in message
> news:d3g5os$27cj$1@digitaldaemon.com...
>
>>Not that I disagree, in principle, but there are still cases where
>>you'd want to recover from an "unrecoverable" error. Consider an
>>environment like Eclipse, which is built totally out of plugins,
>>and there can be hundreds of them. What you're saying is that
>>whenever one of those faults, the whole system should abort, which
>>is definitely not what I'd want it to do.
>
>
> With respect - I'm going to use "with respect" a lot in this thread,
> and I'm going to mean it, because I fear I am going to
> insult/patronise - I think you miss the point. It's easy to do, of
> course, since this irrecoverability is challenging stuff: when I
> read this paragraph I thought, "ah yes, that is an exception". But
> of course it's not, nor are any of the many other examples I've been
> given over the last year or so to counter the principle.
Well, to clear things up, I was mainly responding to your statement:
> First, "Why do you need to force a program to terminate?".
> This one's simple: The program must be forced to terminate because
> it has violated its design.
> 1. As soon as your editor encounters a CP violation, it is, in
> principle and in practice, capable of doing anything, including
> using your work. The only justifiable action, once you've saved (if
> possible) and shut down, is to disable the offending plug-in. (I
> know this because I use an old version of Visual Studio. <G>)
But why would it be mandatory to shut down? If the core of the app is
able to disable the plugin without shutting down, I'd say that's better
(assuming, of course, that internal consistency can be ensured, which it
can be in many cases, and can't be in many other cases; if it is not
clear whether the app is in a consistent state, I agree shutting down
completely is the best thing to do)
> 2. The picture you've painted fails to take into account the effect
> of the extremely high-intolerance of bugs in "irrecovering code".
> Basically, they're blasted out of existence in an extremely short
> amount of time - the code doesn't violate its design, or it doesn't
> get used. period - and the result is high-quality systems.
I don't understand the first sentence, sorry..
>>I mean, when I do something like inspect a value in a debugger,
>>and the value is 150MB and the debugger runs out of memory, I
>>don't want it to stop, just because it can't show me a var (which
>>can just as easily manifest as an assertion error or whatever)...
>
> Out of memory is not an error, it's an exception, so that's just not
> an issue.
Like I said, out of memory can just as well manifest itself later as a
broken contract or whatever. That is completely off the point, though,
I'm trying to address your claim that some errors should force the app
to shut down.
> btw, at no time have I _ever_ said that processes should just stop.
> There should always be some degree of logging of the flaw and, where
> appropriate, an attempt made to shutdown gracefully and with as
> little collateral damage as possible.
I've seen in your other responses that you don't mean uncatchable when
you say unrecoverable. I'm not quite sure what you do mean, then. I
guess it would be a throwable that can be caught, but that doesn't stop
it from propagating ahead?
> So, given that:
> - irrecoverability applies only to contract violations, i.e.
> code that is detected to have violated its design via runtime
> constructs inserted by its author(s) for that purpose
> - an invalid process cannot, by definition, perform validly. It
> can only stop, or perform against its design.
True, but a faulty part of the application should not be taken as if the
whole application is faulty. Like I said, if one is able to disable just
that part of the app, I think that is better than forcing the app to
shut down.
> - "Crashing Early" in practice results in extremely high quality
> code, and rapid turn around of bug diagnosis and fixes
> - D cannot support opt-in/library-based irrecoverability; to
> have it, it must be built in
> do you still think it would be a mistake?
>
> If so, can you explain why?
OK, it is obviously desired in some cases, so I agree it should be
supported by the language, BUT, none of the built-in exceptions should
then be unrecoverable.
xs0

In article <d3g49q$261c$1@digitaldaemon.com>, Matthew says...
>
>Nonetheless, I do have serious doubts that irrecoverability will be
>incorporated into D, since Walter tends to favour "good enough"
>solutions rather than aiming for strict/theoretical best, and
>because the principles and advantages of irrecoverability are not
>yet sufficiently mainstream.
It may be possible to do this in the standard library, though the lack of
deterministic destruction makes things a bit more difficult. it's an idea worth
considering even without Walter's approval--I know some applications where I'd
like this behavior.
Sean

> Nonetheless, I do have serious doubts that irrecoverability will be
> incorporated into D, since Walter tends to favour "good enough" solutions
> rather than aiming for strict/theoretical best, and because the principles
> and advantages of irrecoverability are not yet sufficiently mainstream.
> It's a pity though, because it'd really lift D's head above its peers.
> (And without it, there'll be another area in which C++ will continue to be
> able to claim supremacy, because D cannot support it in library form.)
I think Walter has made the right choices - except the hierarchy has gotten
out of whack. Robust, fault-tolerant software is easier to write with D than
C++.

On Tue, 12 Apr 2005 08:10:10 -0400, Ben Hinkle <ben.hinkle@gmail.com>
wrote:
>>> Maybe we could shorten these ArgumentExceptions to ArgExceptions or
>>> ParamException since it's obvious what Arg and Param mean. So how about
>>> ParamException
>>> ParamNullException
>>> ParamRangeException
>>>
>>
>> Just thinking about this, null and out of range are effectively the same
>> thing, as null is "out of range" for a parameter that "cannot be null'.
>> So
>> we *could* just combine them.
>
> The .Net doc explains that Range is for things that are non-null but
> still illegal (or for primitive types out of range).
> For example if a function
> takes a pointer to an int and the int must not be 5. I think it would be
> handy to have both. A null check is probably 75% of all input checking
> anyway - at least with a project with lots of classes.
Agreed. Could/should we then make Null a subclass of OutOfRange?
>> <Warning: wacky idea>
>> It's a pity the class tree isn't more 'obvious' then we could simply
>> drop
>> the redundant 'Exception' alltogether. eg.
<snip>
> This was suggested in the naming thread. It isn't that bad since the
> Here's
> can be distinguished by package and module names. Now that I think about
> it
> the Exception was used to indicate that it subclasses Exception, which
> seems
> useful.
Why? I mean if we only have "Exception" and no "Error" class then we can
probably say that anything you throw/catch will be a subclass of
"Exception".
> ps - I mistakenly printed out those old threads and now I can symathize
> with
> Walter's statement that removing "dead quotes" from replies is useful -
> probably 75% or more of the printouts were lazy quoting that added
> nothing
> to the thread. One printout was 73 pages long.
Yeah.. I try to cut replies down, but like to leave anything to which I
refer, or respond.
Regan