Sean Kelly <sean@f4.ca> wrote in news:cipncc$1fqb$1@digitaldaemon.com:
> 
> If D doesn't support catching interfaces then it should.  That the compiler doesn't balk at the syntax implies that this is legal and therefore a bug.
> 

I suppose, you're right.


Unfortunately, interfaces are not so useful for the exception hierarchy. I can see only 2 possibilities.

1.) have separate branches for programming errors/environmental errors

Error (implements IError)
   DBError
      QueryError (implements IProgrammingError)
      DBConnectionError (implements IEnvironmentError)

advantage:
By catching IEnvironmentError, it is easy to let IProgrammingErrors
propagate.
disadvantage:
Every exception class must implement either IProgrammingError or
IEnvironmentError. This requires some effort and therefore is unlikely to
work well in practice. Furthermore it's possible to implement both
IProgrammingError and IEnvironmentError by accident.


2.) only use interfaces to tag programming errors

Error
   DBError
      QueryError (implements IProgrammingError)
      DBConnectionError

advantage: Doesn't require much effort for library writers.
disadvantage: To propagate IProgrammingErrors, more work is required:
try {
 blah blah blah
} catch (IProgrammingError e) {
  throw e;
} catch (Error) {
 print ops, sth. is wrong with the data base.
}

That's almost the way it works in Java.

Overall, I like the second approach better. It has less benefits, but is also far less obtrusive.


Regards,

  Farmer.

On Wed, 22 Sep 2004 20:56:17 +0200, Sjoerd van Leent <svanleent@wanadoo.nl> wrote:
> Nick wrote:
>> In article <opseo54ir25a2sq9@digitalmars.com>, Regan Heath says...
>>
>>> [snip]
>>> basically, all the above (except the flawed initial java one) are the same thing, errors that occur at the time of execution, or 'Runtime'. So I am even more sure now that 'RuntimeError' is the best term/name.
>>
>>
>> I agree with your definition, but doesn't this mean that _all_ thrown
>> exceptions/errors are runtime errors?
>>
>> Nick
>>
>>
> I disagree with this. A RuntimeError is an error which occurs when it is layered as deep as Phobos (The runtime environment) or when there is something very wrong with memory access and/or an error not catchable by the compiler, but still a programming fault.

That's not my definition.
I based my definitions off Farmer's here:

<quote>
CheckedExceptions: cause is external: Caller cannot avoid them, consequently a programmer should usually focus on how to *handle* the exception.
</unquote>

in other words:
 - it may not occur all the time, on every execution
 - it may be a temporary failure

What do you mean by "programming fault" exactly? Do you mean the code is simply wrong i.e.

foo(NULL);

throws InvalidParameter, meaning NULL is not acceptable? If so, that is not a runtime exception it's a program exception by my definition.

> All other errors (thrown not as deep as previous are) are normal errors, for example, an error which is thrown when a Date value is incorrect, i.e.: February 30th, 2004.

It depends where that date comes from, if it comes from a file then it's a runtime error, if it's hard coded then it's a program error.

Do you see the distinction my definition tries to make?

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Wed, 22 Sep 2004 14:10:36 +0000 (UTC), Nick <Nick_member@pathlink.com> wrote:
> In article <opseo54ir25a2sq9@digitalmars.com>, Regan Heath says...
>>
>> [snip]
>> basically, all the above (except the flawed initial java one) are the same
>> thing, errors that occur at the time of execution, or 'Runtime'. So I am
>> even more sure now that 'RuntimeError' is the best term/name.
>
> I agree with your definition, but doesn't this mean that _all_ thrown
> exceptions/errors are runtime errors?

I see what you mean, perhaps my definition is a little vague still, basically I looked at Farmers, here:

<quote>
CheckedExceptions: cause is external: Caller cannot avoid them, consequently a programmer should usually focus on how to *handle* the exception.
</unquote>

and came to the conclusion that runtime errors were things that happened which were not a direct result of faulting coding, whereas program errors are a result of faulty coding.

A good example of a program error is invalid parameter, this error occurs when you the programmer forgets to code a check to check a parameter, or maybe hard codes a parameter incorrectly.

A good example of a runtime error is a ConnectionError, you get one of those if the thing you're connecting to is not accepting connections, but there is nothing wrong with the code itself, it will work if you connect to something that is listening.

So you cannot prevent runtime errors but you can prevent/fix program errors.
You want to handle/catch runtime errors, but not program errors.

That is the distinction.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Seeing as different people seems to have different opinions on the definition of a run time error, I think calling anything a RunTimeError will only cause confusion. I suggest avoiding the term altogether.

Nick

In article <opseq5h3u45a2sq9@digitalmars.com>, Regan Heath says...
>
>On Wed, 22 Sep 2004 20:56:17 +0200, Sjoerd van Leent <svanleent@wanadoo.nl> wrote:
>> Nick wrote:
>>> In article <opseo54ir25a2sq9@digitalmars.com>, Regan Heath says...
>>>
>>>> [snip]
>>>> basically, all the above (except the flawed initial java one) are the
>>>> same thing, errors that occur at the time of execution, or 'Runtime'.
>>>> So I am even more sure now that 'RuntimeError' is the best term/name.
>>>
>>>
>>> I agree with your definition, but doesn't this mean that _all_ thrown exceptions/errors are runtime errors?
>>>
>>> Nick
>>>
>>>
>> I disagree with this. A RuntimeError is an error which occurs when it is layered as deep as Phobos (The runtime environment) or when there is something very wrong with memory access and/or an error not catchable by the compiler, but still a programming fault.
>
>That's not my definition.
>I based my definitions off Farmer's here:
>
><quote>
>CheckedExceptions: cause is external: Caller cannot avoid them,
>consequently a programmer should usually focus on how to *handle* the
>exception.
></unquote>
>
>in other words:
>  - it may not occur all the time, on every execution
>  - it may be a temporary failure
>
>What do you mean by "programming fault" exactly? Do you mean the code is simply wrong i.e.
>
>foo(NULL);
>
>throws InvalidParameter, meaning NULL is not acceptable? If so, that is not a runtime exception it's a program exception by my definition.
>
>> All other errors (thrown not as deep as previous are) are normal errors, for example, an error which is thrown when a Date value is incorrect, i.e.: February 30th, 2004.
>
>It depends where that date comes from, if it comes from a file then it's a runtime error, if it's hard coded then it's a program error.
>
>Do you see the distinction my definition tries to make?
>
>Regan
>
>-- 
>Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Thu, 23 Sep 2004 10:24:28 +0000 (UTC), Nick <Nick_member@pathlink.com> wrote:

> Seeing as different people seems to have different opinions on the definition of
> a run time error, I think calling anything a RunTimeError will only cause
> confusion. I suggest avoiding the term altogether.

Well of course IMO other people have the 'wrong' definition of RunTime :)

I think we can all agree runtime is the time at which it's running, can't we?

Given that it's how you interpret the error that confuses things. I think this definition/explaination is what I mean.

<quote me>
I see what you mean, perhaps my definition is a little vague still, basically I looked at Farmers,
here:

<quote farmer>
CheckedExceptions: cause is external: Caller cannot avoid them, consequently a programmer should
usually focus on how to *handle* the exception.
</unquote>

and came to the conclusion that runtime errors were things that happened which were not a direct
result of faulting coding, whereas program errors are a result of faulty coding.

A good example of a program error is invalid parameter, this error occurs when you the programmer
forgets to code a check to check a parameter, or maybe hard codes a parameter incorrectly.

A good example of a runtime error is a ConnectionError, you get one of those if the thing you're
connecting to is not accepting connections, but there is nothing wrong with the code itself, it will
work if you connect to something that is listening.

So you cannot prevent runtime errors but you can prevent/fix program errors.
You want to handle/catch runtime errors, but not program errors.

That is the distinction.
</quote me>

Regan

> Nick
>
> In article <opseq5h3u45a2sq9@digitalmars.com>, Regan Heath says...
>>
>> On Wed, 22 Sep 2004 20:56:17 +0200, Sjoerd van Leent
>> <svanleent@wanadoo.nl> wrote:
>>> Nick wrote:
>>>> In article <opseo54ir25a2sq9@digitalmars.com>, Regan Heath says...
>>>>
>>>>> [snip]
>>>>> basically, all the above (except the flawed initial java one) are the
>>>>> same thing, errors that occur at the time of execution, or 'Runtime'.
>>>>> So I am even more sure now that 'RuntimeError' is the best term/name.
>>>>
>>>>
>>>> I agree with your definition, but doesn't this mean that _all_ thrown
>>>> exceptions/errors are runtime errors?
>>>>
>>>> Nick
>>>>
>>>>
>>> I disagree with this. A RuntimeError is an error which occurs when it is
>>> layered as deep as Phobos (The runtime environment) or when there is
>>> something very wrong with memory access and/or an error not catchable by
>>> the compiler, but still a programming fault.
>>
>> That's not my definition.
>> I based my definitions off Farmer's here:
>>
>> <quote>
>> CheckedExceptions: cause is external: Caller cannot avoid them,
>> consequently a programmer should usually focus on how to *handle* the
>> exception.
>> </unquote>
>>
>> in other words:
>>  - it may not occur all the time, on every execution
>>  - it may be a temporary failure
>>
>> What do you mean by "programming fault" exactly? Do you mean the code is
>> simply wrong i.e.
>>
>> foo(NULL);
>>
>> throws InvalidParameter, meaning NULL is not acceptable? If so, that is
>> not a runtime exception it's a program exception by my definition.
>>
>>> All other errors (thrown not as deep as previous are) are normal errors,
>>> for example, an error which is thrown when a Date value is incorrect,
>>> i.e.: February 30th, 2004.
>>
>> It depends where that date comes from, if it comes from a file then it's a
>> runtime error, if it's hard coded then it's a program error.
>>
>> Do you see the distinction my definition tries to make?
>>
>> Regan
>>
>> --
>> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

In article <opses4yynq5a2sq9@digitalmars.com>, Regan Heath says...
>
>On Thu, 23 Sep 2004 10:24:28 +0000 (UTC), Nick <Nick_member@pathlink.com> wrote:
>
>> Seeing as different people seems to have different opinions on the
>> definition of
>> a run time error, I think calling anything a RunTimeError will only cause
>> confusion. I suggest avoiding the term altogether.
>
>Well of course IMO other people have the 'wrong' definition of RunTime :)
>
>I think we can all agree runtime is the time at which it's running, can't we?
>
>Given that it's how you interpret the error that confuses things. I think this definition/explaination is what I mean.
>
><quote me>
>I see what you mean, perhaps my definition is a little vague still,
>basically I looked at Farmers,
>here:
>
><quote farmer>
>CheckedExceptions: cause is external: Caller cannot avoid them,
>consequently a programmer should
>usually focus on how to *handle* the exception.
></unquote>
>
>and came to the conclusion that runtime errors were things that happened
>which were not a direct
>result of faulting coding, whereas program errors are a result of faulty
>coding.
>
>A good example of a program error is invalid parameter, this error occurs
>when you the programmer
>forgets to code a check to check a parameter, or maybe hard codes a
>parameter incorrectly.
>
>A good example of a runtime error is a ConnectionError, you get one of
>those if the thing you're
>connecting to is not accepting connections, but there is nothing wrong
>with the code itself, it will
>work if you connect to something that is listening.
>
>So you cannot prevent runtime errors but you can prevent/fix program
>errors.
>You want to handle/catch runtime errors, but not program errors.
>
>That is the distinction.
></quote me>
>
>Regan
>
>> Nick
>>
>> In article <opseq5h3u45a2sq9@digitalmars.com>, Regan Heath says...
>>>
>>> On Wed, 22 Sep 2004 20:56:17 +0200, Sjoerd van Leent <svanleent@wanadoo.nl> wrote:
>>>> Nick wrote:
>>>>> In article <opseo54ir25a2sq9@digitalmars.com>, Regan Heath says...
>>>>>
>>>>>> [snip]
>>>>>> basically, all the above (except the flawed initial java one) are the
>>>>>> same thing, errors that occur at the time of execution, or 'Runtime'.
>>>>>> So I am even more sure now that 'RuntimeError' is the best term/name.
>>>>>
>>>>>
>>>>> I agree with your definition, but doesn't this mean that _all_ thrown exceptions/errors are runtime errors?
>>>>>
>>>>> Nick
>>>>>
>>>>>
>>>> I disagree with this. A RuntimeError is an error which occurs when it
>>>> is
>>>> layered as deep as Phobos (The runtime environment) or when there is
>>>> something very wrong with memory access and/or an error not catchable
>>>> by
>>>> the compiler, but still a programming fault.
>>>
>>> That's not my definition.
>>> I based my definitions off Farmer's here:
>>>
>>> <quote>
>>> CheckedExceptions: cause is external: Caller cannot avoid them,
>>> consequently a programmer should usually focus on how to *handle* the
>>> exception.
>>> </unquote>
>>>
>>> in other words:
>>>  - it may not occur all the time, on every execution
>>>  - it may be a temporary failure
>>>
>>> What do you mean by "programming fault" exactly? Do you mean the code is simply wrong i.e.
>>>
>>> foo(NULL);
>>>
>>> throws InvalidParameter, meaning NULL is not acceptable? If so, that is not a runtime exception it's a program exception by my definition.
>>>
>>>> All other errors (thrown not as deep as previous are) are normal
>>>> errors,
>>>> for example, an error which is thrown when a Date value is incorrect,
>>>> i.e.: February 30th, 2004.
>>>
>>> It depends where that date comes from, if it comes from a file then
>>> it's a
>>> runtime error, if it's hard coded then it's a program error.
>>>
>>> Do you see the distinction my definition tries to make?
>>>
>>> Regan
>>>
>>> --
>>> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
>>
>>
>
>
>
>-- 
>Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Sorry for the late reply (and for the double post, stupid enter key...)

In article <opses4yynq5a2sq9@digitalmars.com>, Regan Heath says...
>
>> Seeing as different people seems to have different opinions on the
>> definition of
>> a run time error, I think calling anything a RunTimeError will only cause
>> confusion. I suggest avoiding the term altogether.
>
>Well of course IMO other people have the 'wrong' definition of RunTime :)

As I'm sure you know there's no such thing as a 'wrong' definition. There may however be inconsistencies between different definitions of the same term.

>I think we can all agree runtime is the time at which it's running, can't we?

Yes.

>Given that it's how you interpret the error that confuses things. I think this definition/explaination is what I mean.
>
><quote me>
>I see what you mean, perhaps my definition is a little vague still,
>basically I looked at Farmers,
>here:
>
><quote farmer>
>CheckedExceptions: cause is external: Caller cannot avoid them,
>consequently a programmer should
>usually focus on how to *handle* the exception.
></unquote>
>
>and came to the conclusion that runtime errors were things that happened
>which were not a direct
>result of faulting coding, whereas program errors are a result of faulty
>coding.

In short, you call something a runtime error if the _cause_ of the error happens at runtime, ie. it is external, whereas internal errors (bugs) you define not to be runtime errors. But, first of all, in the context of compiled languages, a runtime error is very often defined as any error that _occurs_ at runtime, in other words anything that is not a compile time error. So this definition might lead to confusion.

Secondly I'm not sure if I agree that dividing exception classes into bugs/nonbug classes is very practical. For example in the date example, it's hard to tell (when throwing the exception) whether the invalid date came directly from the user ("runtime error") or a bad algorithm/hard coded date ("program error".)

Nick

In article <Xns8FB5AEC4C993AitsFarmer@63.105.9.61>, Farmer says...
>
>*) "Best Practices for Exception Handling" http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html

Thanks for the links.  My Java experience is quite a few years out of date and this clarified some suspicions I had about checked vs. unchecked exceptions. While I like the idea of differentiating between programmer errors and other erros, I'm not sure how well this concept maps into D, because D (and C++) don't have any language support for checked exceptions.  Further, I would argue (as I think I did in another part of this thread) that programmer errors should be handled by DBC and AssertErrors rather than inheriting from some alternate portion of the exception heirarchy.  ie. I don't see much utility in having a programmer define separate generic catch blocks for checked and unchecked exceptions.

>My insight about (Java) exceptions is, that in practise, Java programmers use exceptions very differently. This is somewhat surprising, since Java progammers usually share a very uniform way of dealing with problems. Indeed recommendations of actual Java programmers often contradict each other.

This has been my experience with Java as well, and is one reason why it never really appealed to me as a language.  I think D would do better to somewhat follow C++ in this case and prefer a less structured and expansive exception heirarchy, at least so far as Phobos is concerned.  All exceptions are unchecked by language design, but ideally still heirarchically arranged to allow for easy handling of different sorts of errors.


Sean