[ot]obj oriented language, the case of error

[asetof...@gmail.com]

In my opinion obj oriented languages are not complete until it is know one error element for each type.

Each operation or function or operator elaborate error element obj return error elements obj

For example for T=u8 (unsigned char 8 bit ) it could be FF
T=i8 (signed char 8 bit, it could be 128)
T=double it could be one NaN double
if I have type list<T> than its error
element could be one list of element of type T of one element, and that element is the error element of T.

[Öö Tiib]

On Monday, 2 October 2017 08:34:04 UTC+3, asetof...@gmail.com wrote:
> In my opinion obj oriented languages are not complete until it is know
> one error element for each type.
>
> Each operation or function or operator elaborate error element obj
> return error elements obj

In C++ we usually signal about unrecoverable errors with exceptions.
We may still quite often need "missing" state ("unknown", "unavailable",
"not yet retrieved", "nil") by program logic.

>
> For example for T=u8 (unsigned char 8 bit ) it could be FF
> T=i8 (signed char 8 bit, it could be 128)
> T=double it could be one NaN double
> if I have type list<T> than its error
> element could be one list of element of type T of one element, and
> that element is the error element of T.

Reserving one of valid states to represent missing state may be
OK but you have to keep track of it yourself manually, language does
not understand it. For safe handling of potentially missing value would
be to use std::optional<T>.

[asetof...@gmail.com]

Error is not a state of the program

It is one set of error objects

In practice one operation or function fail and produce one error object I call it e in the time t0

Than the set S_t={objects build apply operations on e}
in the time t>=t0 is the set error one can not safe use

All the remain sys or objects are ok

[Jerry Stuckle]

Incorrect. Error is a program state - for instance attempting to open a
read-only file for output. You can handle the error there, or in C++,
throw an exception to allow the error to be handled in a higher routine.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[asetof...@gmail.com]

Open a read only file for writing...
in a obj oriented language

fstream j("file name", "w");

j object is the error obj for filestream class
because can not open one read only file for write

So I would check if open is ok in this way

if(j.e) error();

if some function use j obj will fail or produce error objects

writefile(j, "123") will fail etc
v=readfile(j)
produce error obj for v variable type etc

[Jerry Stuckle]

No, j is still a filestream object. It has a state which indicates an
error. But it's type has not changed.

[asetof...@gmail.com]

Jerry Stuckle wrote:

- show quoted text -

No, j is still a filestream object. It has a state which indicates an
error. But it's type has not changed.

-----
I write
Yes j is still a filestream object
and "has a state wich indicates an error" and its type is not changed

Ok what about in the filestream class there is too one integer
int e;
If something goes in error with filestream j than it is written
j.e=1
and if j.e==1 than the object j is one error object
for the filestream type

If any operator or function is applied on j
first of all it will check if j.e==1 if yes
should produce fail operations and error objects of respective type
of return

For exaple String w=j.readline()
should copy in w the error object for the string
(because j.e==1)

So w.e==1 too for example

[Jerry Stuckle]

Yes, but that is because the fstream object is behaving properly - it
does not represent a file due to the error state, and does not allow any
operations on the object which require a file representation.

It is not an error object. It is a fstream object in an error state.
Something completely different.

[asetof...@gmail.com]

For me "error object" is one special object (among all objects can be in its type)

one real object with its memory etc all ok, only differ with a bit on, or one its member for example int ==1

example for
0..255 type number (8 bit unsigned) would be the value 255
0..0xFFFFFFFF type number error object would be
0xFFFFFFFF
[one should have 0..0xFFFFFFFE for normal value and 0xFFFFFFFF for error ]
for
class name{int e; char*a; u32 sz};
with
name x;
should be the object with x.e==1
(if it is 0 than all ok)
And so on

[Jerry Stuckle]

On 10/2/2017 6:15 PM, asetof...@gmail.com wrote:
> For me "error object" is one special object (among all objects can be in its type)
>
> one real object with its memory etc all ok, only differ with a bit on, or one its member for example int ==1
>

Nope. This is an fstream object with a state that indicates an error.

It is not an error object.

> example for
> 0..255 type number (8 bit unsigned) would be the value 255
> 0..0xFFFFFFFF type number error object would be
> 0xFFFFFFFF
> [one should have 0..0xFFFFFFFE for normal value and 0xFFFFFFFF for error ]
> for
> class name{int e; char*a; u32 sz};
> with
> name x;
> should be the object with x.e==1
> (if it is 0 than all ok)
> And so on
>

It makes no difference. It is an fstream object - as defined in the
source code. The fact there was an open error does not change that.

And in OO, a properly defined object will only allow valid operations;
it will not allow invalid operations. For instance, writing to an
fstream which has not been opened will also cause an error.

You REALLY need to understand proper OO design and terminology. It is
obvious you don't (as well as having a crappy programming style that no
project manager in his right mind would accept).

[asetof...@gmail.com]

I call it "error object" because a name other to indicate it, to describe it, its way of to be: I don't know... It is not one malfunction object or one object has less memory it has to have
it has one bit on or one element ==1
or it is one value of one range,
used to indicate that object is result of one error operation

[Jerry Stuckle]

You are calling it the wrong thing. It is an fstream object with an
error status.

[asetof...@gmail.com]

Ok you are right until I write something that can run...
Possible the first implementation of this error propagation thru object
would be a general linked list in C++ with few function in it.

But something begin to be ok

f(){
T r;

// and the (void) constructor of r
//produce in r the error object
//Now r is the error object
// all obj build using r are error obj

r=b

// if b is not the error obj than r is ok

[asetof...@gmail.com]

What about these law for the objects error set:

1)Each object, in each type it is a pointer to memory
2)If that pointer it is 0 or NULL
we call it: "Object error for that type"
3)any operation find errors produce only objects error (null pointers)
4) Each print function had to print the error object as ErrorObj type.

For example in "int n;" n would be a pointer in a memory of 32 bits
the really n would be *n or something as that

[Fred.Zwarts]

schreef in bericht
news:e7ffb7a8-1567-42e4...@googlegroups.com...

The values FF (hex) for an unsigned byte and 128 (dec) for a signed byte are
currently valid values, which are used on many occasions. A programming
language should not change that. Suppose such a value must be read from or
written to a device register in a device driver. Would that be possible in
the language you propose?

[asetof...@gmail.com]

I remember for the C standard are ok signed char values -127..127
So -128 could be implemented as one error value...

[Scott Lurndal]

asetof...@gmail.com writes:
>I remember for the C standard are ok signed char values -127..127
>So -128 could be implemented as one error value...

And the bit pattern for -128 in a twos-complement system is
what, exactly?

[asetof...@gmail.com]

---
It would be 0x80 or 128 as unsigned
(1000 0000 as binary)
Right?

[red floyd]

And why should that considered to be an invalid value?

"Invalid" values are defined by the program.

[Scott Lurndal]

No. It would be 1 1000 0000. It can't be represented in 8 bits.

$ printf '%x\n' $(( -128 ))
ffffffffffffff80

[James R. Kuyper]

??

~/testprog(108) cat schar_min.c
#include <limits.h>
#include <stdio.h>

int main(void)
{
union{
signed char sc;
unsigned char uc;
} u = {SCHAR_MIN};
printf("%x %d\n", u.uc, u.sc==-128);
}

~/testprog(111) gcc -std=c99 -pedantic -Wall -Wpointer-arith
-Wcast-align -Wstrict-prototypes -Wmissing-prototypes schar_min.c -o
schar_min
~/testprog(112) ./schar_min
80 1

[Bo Persson]

On 2017-10-12 17:28, asetof...@gmail.com wrote:
> I remember for the C standard are ok signed char values -127..127
> So -128 could be implemented as one error value...
>

That's the MINIMUM required range. Most implementations already have
-128..127 as valid values.


Bo Persson