April 12, 2005
> 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>


April 12, 2005
"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?



April 12, 2005
"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


April 12, 2005
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.
April 12, 2005
"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.


April 12, 2005
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


April 12, 2005
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
April 12, 2005
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


April 12, 2005
> 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++.


April 12, 2005
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