Farmer <itsFarmer.@freenet.de> wrote in
news:Xns8FB1F10BEFD73itsFarmer@63.105.9.61:
[snip]
> Initially I thought, that the more general exceptions, should be available as Low-, Mid- and High- Severity exceptions. The problem is that one would either have to make up 3 different names for one exception or have 3 classes that have the same name, but are in different modules. So, it seems this doesn't work so well with generic exceptions :-(
> 
> So, It doesn't work!
> 

Example for the problem
-----------------------

The obvious exception hierarchy for a database package could be:

DBError
   QueryError
   DBConnectionError


* QueryError is thrown if a query cannot be processed due to invalid syntax of an SQL statement

* DBConnectionError is thrown if the connection to the DBMS cannot be established or breaks down.

QueryError indicates a programming error (midseverity) while DBConnectionError indicates an environmental error (lowseverity). Unfortunately, it is impossible to include this information (programming vs. environmental error) in the hierarchy, since both exceptions already inherit from the general DBError class.



Multi-Inheritance
-----------------

One solution might be to use interfaces, as they allow multi-inheritance.


DBError
   QueryError (implements IProgrammingError)
   DBConnectionError (implements IEnvironmentError)


Currently, I'm not sure whether D supports catching interfaces:
DMD compiled a simple example that catches an interface; at runtime the
exception was even correctly catched, but the pointer-handle (reference) was
bogus: when a method was called on the pointer an AV occured, although the
pointer wasn't null.

Even if D supports interfaces for exceptions. Every exception class has to explicitly dispatch all methods of an exception interface. A mixin should help here, though.



Farmer.

On Mon, 20 Sep 2004 15:13:17 +0000 (UTC), Farmer <itsFarmer.@freenet.de> wrote:
> Farmer <itsFarmer.@freenet.de> wrote in
> news:Xns8FB1F10BEFD73itsFarmer@63.105.9.61:
>
>> "Ben Hinkle" <bhinkle@mathworks.com> wrote in
>> news:cia7sd$1n6u$1@digitaldaemon.com:
>>
>>> Also I'd like to toss around some more names (Checked and Unchecked
>>> don't mean too much to me).
>>
>> They don't mean anything to me, either. I thought about other names, but
>> always came up with names that I feel are too specific and provoke wrong
>> ad- hoc decisions on the part of the programmer.
>> As an mnemonic aid I think of "Checked/Unchecked" as "I should check the
>> exception" and "I should leave it unchecked".
>>
>
> Just some alternative names for "checked/unchecked", that I made up myself
> or came across in articles, forums or wiki pages.
>
> unchecked exception:
> --------------------
> ProgrammingError
> UnexpectedError
> UnpredictableError
> UnrecoverableError
> AvoidableError
> LogicalError
>
> checked exception:
> ------------------
> GeneralError
> ExternalError
> ExpectedError
> PredictableError
> RecoverableError
> UnavoidableError
> EnvironmentError
> EnvironmentalError
>
>
> My favorites are ProgrammingError and EnvironmentError or GeneralError.


Going by your previous descriptions..

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

this implies to me the problem is (perhaps) unique to this execution of the program, in other words it occurs only during runtime, as such I prefer 'RuntimeError'.


> UncheckedExceptions: cause is internal: Caller can avoid them, consequently a programmer should usually focus on how to *prevent* the exception.

this implies to me the problem is in the code, in other words every execution will have this problem, as such I prefer 'ProgramError' or 'DebugError'.


Regan

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

On Mon, 20 Sep 2004 15:13:18 +0000 (UTC), Farmer <itsFarmer.@freenet.de> wrote:
> Farmer <itsFarmer.@freenet.de> wrote in
> news:Xns8FB1F10BEFD73itsFarmer@63.105.9.61:
> [snip]
>> Initially I thought, that the more general exceptions, should be
>> available as Low-, Mid- and High- Severity exceptions. The problem is
>> that one would either have to make up 3 different names for one
>> exception or have 3 classes that have the same name, but are in
>> different modules. So, it seems this doesn't work so well with generic
>> exceptions :-(
>>
>> So, It doesn't work!
>>
>
> Example for the problem
> -----------------------
>
> The obvious exception hierarchy for a database package could be:
>
> DBError
>    QueryError
>    DBConnectionError
>
>
> * QueryError is thrown if a query cannot be processed due to invalid syntax
> of an SQL statement
>
> * DBConnectionError is thrown if the connection to the DBMS cannot be
> established or breaks down.
>
> QueryError indicates a programming error (midseverity) while
> DBConnectionError indicates an environmental error (lowseverity).
> Unfortunately, it is impossible to include this information (programming vs.
> environmental error) in the hierarchy, since both exceptions already inherit
> from the general DBError class.
>
>
>
> Multi-Inheritance
> -----------------
>
> One solution might be to use interfaces, as they allow multi-inheritance.
>
>
> DBError
>    QueryError (implements IProgrammingError)
>    DBConnectionError (implements IEnvironmentError)
>
>
> Currently, I'm not sure whether D supports catching interfaces:
> DMD compiled a simple example that catches an interface; at runtime the
> exception was even correctly catched, but the pointer-handle (reference) was
> bogus: when a method was called on the pointer an AV occured, although the
> pointer wasn't null.
>
> Even if D supports interfaces for exceptions. Every exception class has to
> explicitly dispatch all methods of an exception interface. A mixin should
> help here, though.

I think if you re-factor the tree into something like:
(using my preferred names, yours are in ())

|RuntimeError(EnvironmentError)
| |-DBError
|    |-DBConnectionError
|
|ProgramError(ProgrammingError)
| |-SQLError
|    |-SQLSyntaxError

then the problem vanishes.

The justification for this refactoring is that SQLSyntaxError refers specifically to an SQL statement, which need not be associated with any particular database and/or connection to a database, i.e. you might write this function:

bool verifySqlSyntax(char[] string){}

and it might throw the SQLSyntaxError.

Regan

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

Regan Heath <regan@netwin.co.nz> wrote in news:opsem9tqo15a2sq9@digitalmars.com:

[snip]
> 
> 
> Going by your previous descriptions..
> 
>> CheckedExceptions: cause is external: Caller cannot avoid them, consequently a programmer should usually focus on how to *handle* the exception.
> 
> this implies to me the problem is (perhaps) unique to this execution of the program, in other words it occurs only during runtime, as such I prefer 'RuntimeError'.
> 

I wouldn't use the term 'RuntimeError' as it is too overloaded. Different people use it differently:

RuntimeError = mainly programming errors [designers of Java]
RuntimeError = errors of the JVM [critique of Java's exception hierarchy]
RuntimeError = errors detected by the python interpreter [designers of the
python]
RuntimeError = anything that cannot be determined at compile time [you]

Regan Heath <regan@netwin.co.nz> wrote in news:opsem953pg5a2sq9@digitalmars.com:

> I think if you re-factor the tree into something like:
> (using my preferred names, yours are in ())
> 
>|RuntimeError(EnvironmentError)
>| |-DBError
>|    |-DBConnectionError
>|
>|ProgramError(ProgrammingError)
>| |-SQLError
>|    |-SQLSyntaxError
> 
> then the problem vanishes.

The problem is, that some/most people want to have a common base class for all exceptions of a data base package.


> 
> The justification for this refactoring is that SQLSyntaxError refers specifically to an SQL statement, which need not be associated with any particular database and/or connection to a database, i.e. you might write this function:

Actually, it isn't always clear whether an SQLSyntaxError is a programming or an environmental error, since it depends on the database what syntax is supported.


> 
> bool verifySqlSyntax(char[] string){}
> 
> and it might throw the SQLSyntaxError.
> 
> Regan
> 

In article <Xns8FB5AEC64E2C6itsFarmer@63.105.9.61>, Farmer says...
>
>Multi-Inheritance
>-----------------
>
>One solution might be to use interfaces, as they allow multi-inheritance.
>
>DBError
>   QueryError (implements IProgrammingError)
>   DBConnectionError (implements IEnvironmentError)
>
>Currently, I'm not sure whether D supports catching interfaces:
>DMD compiled a simple example that catches an interface; at runtime the
>exception was even correctly catched, but the pointer-handle (reference) was
>bogus: when a method was called on the pointer an AV occured, although the
>pointer wasn't null.

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.


Sean

On Tue, 21 Sep 2004 08:34:17 +0000 (UTC), Farmer <itsFarmer.@freenet.de> wrote:

> Regan Heath <regan@netwin.co.nz> wrote in
> news:opsem953pg5a2sq9@digitalmars.com:
>
>> I think if you re-factor the tree into something like:
>> (using my preferred names, yours are in ())
>>
>> |RuntimeError(EnvironmentError)
>> | |-DBError
>> |    |-DBConnectionError
>> |
>> |ProgramError(ProgrammingError)
>> | |-SQLError
>> |    |-SQLSyntaxError
>>
>> then the problem vanishes.
>
> The problem is, that some/most people want to have a common base class for all exceptions of a data base package.

Why?

I assume so they can go

catch(DBError e) {
}

to catch any/all errors with the DB.

>> The justification for this refactoring is that SQLSyntaxError refers
>> specifically to an SQL statement, which need not be associated with any
>> particular database and/or connection to a database, i.e. you might write
>> this function:
>
> Actually, it isn't always clear whether an SQLSyntaxError is a programming or
> an environmental error, since it depends on the database what syntax is
> supported.

I didn't know that.

So there are 2 types of syntax error, a program one and a runtime one.

If you use program and runtime top level exceptions there is no way you can put all DB errors in the same tree, however, I don't think it matters, after all you don't want to catch the program errors, only the runtime ones so..

|RuntimeError(EnvironmentError)
| |-DBError
|    |-DBConnectionError
|    |-SQLSyntaxError
|
|ProgramError(ProgrammingError)
| |-ProgramDBError
|    |-ProgramSQLSyntaxError

basically make the names of the program errors the same as the runtime ones, except with a prefix or something (after all you're not catching them in general so the runtime one should have the easy/intuitive name)

Regan

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

On Tue, 21 Sep 2004 08:34:14 +0000 (UTC), Farmer <itsFarmer.@freenet.de> wrote:
> Regan Heath <regan@netwin.co.nz> wrote in
> news:opsem9tqo15a2sq9@digitalmars.com:
>
> [snip]
>>
>>
>> Going by your previous descriptions..
>>
>>> CheckedExceptions: cause is external: Caller cannot avoid them,
>>> consequently a programmer should usually focus on how to *handle* the
>>> exception.
>>
>> this implies to me the problem is (perhaps) unique to this execution of
>> the program, in other words it occurs only during runtime, as such I
>> prefer 'RuntimeError'.
>>
>
> I wouldn't use the term 'RuntimeError' as it is too overloaded. Different
> people use it differently:
>
> RuntimeError = mainly programming errors [designers of Java]

this is just plain wrong.

> RuntimeError = errors of the JVM [critique of Java's exception hierarchy]

which is why they changed it to this, which IMO is identical to

> RuntimeError = anything that cannot be determined at compile time [you]

which is my own understanding, and is also identical to

> RuntimeError = errors detected by the python interpreter [designers of the python]

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.

Regan

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

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

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.

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.

Regards,
Sjoerd