Missing exception classes in the repository

[Eric Bezault]

Is there a reason why only half of the exception classes
have been checked-in in:

    branches/EiffelSoftware/library/kernel/exceptions

The class EXCEPTION_MANAGER needs all exception classes
in order to compile, even those in:

    $ISE_EIFFEL/library/kernel/exceptions

Also, why is this new cluster named 'exceptions' and not
'exception'? I thought that in the Eiffel world we tried
to name things in singular. Apart from 'structures' which
resists this principle, otherwise we have 'list', 'set',
'table', ...

--
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
freeelks-devel@...
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Emmanuel Stapf]

> Is there a reason why only half of the exception classes have
> been checked-in in:

This is why the routine which references all of them should be builtin,
indeed there are exceptions that only the Eiffel Software is going to
trigger and we do not want them to be in FreeELKS. They haven't been made
builtin yet due to some limitations with our builtin mechanism, but
hopefully within the next two weeks it will be solved.

> Also, why is this new cluster named 'exceptions' and not
> 'exception'? I thought that in the Eiffel world we tried to
> name things in singular. Apart from 'structures' which
> resists this principle, otherwise we have 'list', 'set', 'table', ...

no reason. We can easily fix this.

Manu


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
freeelks-devel@...
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Eric Bezault]

Emmanuel Stapf [ES] wrote:
>> Is there a reason why only half of the exception classes have
>> been checked-in in:
>
> This is why the routine which references all of them should be builtin,

I would say this is why this routine should not exist at all.
The fact that exceptions have a code associated to them should
be transparent, and not a corner-stone of their implementation.
Let's make exception real objects, and not just wrappers around
an exception code. I'd rather have a clean exception Eiffel
class design, even if it makes its internal implementation
harder, than the reverse.

> indeed there are exceptions that only the Eiffel Software is going to
> trigger and we do not want them to be in FreeELKS.

The first exception class that gec reported to be missing
was NO_MORE_MEMORY. It's hard to believe that only Eiffel
Software is going to trigger this exception.

On the other hand, COM_FAILURE seems very peculiar to COM
to me. Isn't EiffelCOM a better place for it?

--
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
freeelks-devel@...
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Emmanuel Stapf]

> Let's make exception real objects, and not just wrappers
> around an exception code. I'd rather have a clean exception
> Eiffel class design, even if it makes its internal
> implementation harder, than the reverse.

Yes, but we have constraints and cannot spend too much time when having a
few private routines do the trick. I would say for now that those routines
should be private until we can make it better if we can.
 
> > indeed there are exceptions that only the Eiffel Software
> is going to
> > trigger and we do not want them to be in FreeELKS.
>
> The first exception class that gec reported to be missing was
> NO_MORE_MEMORY. It's hard to believe that only Eiffel
> Software is going to trigger this exception.

This is strange. it should indeed be in ELKS.

> On the other hand, COM_FAILURE seems very peculiar to COM to
> me. Isn't EiffelCOM a better place for it?

It is going to disappear after the builtin are completed. It is part of our
basic exceptions since we have a special handling of COM in our runtime.

Manu


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
freeelks-devel@...
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Eric Bezault]

Emmanuel Stapf [ES] wrote:
>> Let's make exception real objects, and not just wrappers
>> around an exception code. I'd rather have a clean exception
>> Eiffel class design, even if it makes its internal
>> implementation harder, than the reverse.
>
> Yes, but we have constraints and cannot spend too much time when having a
> few private routines do the trick. I would say for now that those routines
> should be private until we can make it better if we can.

Yes, I heard that many times in the past. And then I'm told
that we cannot change it anymore for a better design because
it might break existing code. I'm really in favor of doing
things right from the start, even if it takes more time.
This is in line with the Eiffel spirit.

The first thing that struck me when I looked at the design
of these exception classes, apart from the fact that too
much importance was given to the exception code, is that
too many operations have to go to EXCEPTION_MANAGER. Why
EXCEPTION.raise has to go to the exception manager? Why
is `developer_raise' a built-in feature of EXCEPTION_MANAGER
and not of EXCEPTION? Why does EXCEPTION_MANAGER have to
keep track of ignored exceptions and others in sets of types
instead of that being implemented directly in the EXCEPTION
class? As I said earlier, this design looks to me as if we
have exception codes, a wrapper around them to make them look
like objects, and have everything centralized in the exception
manager. This is not the idea that I had of an object-oriented
way of implementing exceptions. This looks more like dressing
the old way of implementing exceptions with some object
wrappers. I was expecting a real object-oriented way of
implementing exceptions.

--
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
freeelks-devel@...
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Ted [ES]]

Some javascript/style in this post has been disabled (why?)

> The first thing that struck me when I looked at the design

> of these exception classes, apart from the fact that too
> much importance was given to the exception code, is that
> too many operations have to go to EXCEPTION_MANAGER. Why
> EXCEPTION.raise has to go to the exception manager? Why
> is `developer_raise' a built-in feature of EXCEPTION_MANAGER
> and not of EXCEPTION? Why does EXCEPTION_MANAGER have to
> keep track of ignored exceptions and others in sets of types
> instead of that being implemented directly in the EXCEPTION
> class? As I said earlier, this design looks to me as if we
> have exception codes, a wrapper around them to make them look
> like objects, and have everything centralized in the exception
> manager. This is not the idea that I had of an object-oriented
> way of implementing exceptions. This looks more like dressing
> the old way of implementing exceptions with some object
> wrappers. I was expecting a real object-oriented way of
> implementing exceptions.

 

My feeling is that as you see, now EXCEPTION is clean and clear enough.

This is one of the benefits implementations are put in EXCEPTION_MANAGER.

 

The reason EXCEPTION_MANAGER keeps track of ignored exceptions is that ignoring

exceptions is an operation of types, rather than per object. So it doesn't make sense

to have this in EXCEPTION class.

 

 

I am not too surprised at the arguments against many routines of implementation in 

EXCEPTION_MANAGER, since they could be useless for other implementations. What you

see here is actually an implementation of the class from ISE, where we try to implement

in Eiffel code as much as possible. The problem is we need a suitable way to seperate

what is really needed in elks and implementations. `built-in' mechanism would be

used when possible as Manu said. But I realized `built-in' mechanism may not be sufficient,

because those routines will be still there.

 

I am not sure what you think the "a real object-oriented way" is.

On ISE part, only those exceptions raised by the runtime has to do with exception code.

Clients don't have to care about exception code. They can do whatever they want by

object-oriented approach.

What you see so many "code" in the EXCEPTION_MANAGER is just because we do the implementation in

Eiffel code (not creating objects in the runtime). For now,

the ISE runtime doesn't have to know about the detail of exception object by using

exception code. With this, we could go without EAO in the further for small systems,

i.e embeded, by providing a proper implementation of EXCEPTION_MANAGER.

And I agree to make private `type_of_code' and `exception_from_code' in EXCEPTION_MANAGER.

The only reason they are exported is for EXCEPTIONS, so not private but exported to

EXCEPTIONS.

 

Ted

 

 

 

 

 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
freeelks-devel@...
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Eric Bezault]

Ted [ES] wrote:
> My feeling is that as you see, now EXCEPTION is clean and clear enough.
> This is one of the benefits implementations are put in EXCEPTION_MANAGER.

This is a strange answer. I don't understand why it makes it
clean and clear. It's just unnecessarily delegating its
implementation to an auxiliary class. If you want to see
the class without its implementation, just use the short form.
I would find it very cumbersome if for each class, say STRING,
TUPLE, etc. we had to have an auxiliary class, STRING_MANAGER,
TUPLE_MANAGER, etc. to put its implementation. I don't
consider that as a benefit.

> The reason EXCEPTION_MANAGER keeps track of ignored exceptions is that
> ignoring
> exceptions is an operation of types, rather than per object. So it
> doesn't make sense
> to have this in EXCEPTION class.

What would make sense would be to implement it in class
EXCEPTION as a once-per-type. If not supported yet, then
we can find ways to simulate it without the need for
EXCEPTION_MANAGER. What is not very nice with your
implementation is that it uses ARRAYED_SET, which adds
another unwanted dependency to the container clusters
of EiffelBase.

> I am not too surprised at the arguments against many routines of
> implementation in
> EXCEPTION_MANAGER, since they could be useless for other
> implementations. What you
> see here is actually an implementation of the class from ISE, where we
> try to implement
> in Eiffel code as much as possible. The problem is we need a suitable
> way to seperate
> what is really needed in elks and implementations. `built-in' mechanism
> would be
> used when possible as Manu said. But I realized `built-in' mechanism may
> not be sufficient,
> because those routines will be still there.

I don't think we need zillion built-in features to implement
exceptions. The runtime is able to deal with manifest strings,
manifest tuples, manifest arrays, without having to add built-in
features, why should it be different for exceptions.

> I am not sure what you think the "a real object-oriented way" is.

Where objects are not just records.

> On ISE part, only those exceptions raised by the runtime has to do with
> exception code.
> Clients don't have to care about exception code. They can do whatever
> they want by
> object-oriented approach.
> What you see so many "code" in the EXCEPTION_MANAGER is just because we
> do the implementation in
> Eiffel code (not creating objects in the runtime). For now,
> the ISE runtime doesn't have to know about the detail of exception
> object by using
> exception code.

And that's a mistake in my opinion. The runtime has to know
about strings, arrays, tuples without exposing the implementation
details to the programmers. I think that it should be the same
for exceptions.

> With this, we could go without EAO in the further for
> small systems,
> i.e embeded, by providing a proper implementation of EXCEPTION_MANAGER.

But that won't be Eiffel as specified by ECMA anymore.

--
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
freeelks-devel@...
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Ted [ES]]

> Ted [ES] wrote:
>> My feeling is that as you see, now EXCEPTION is clean and clear enough.
>> This is one of the benefits implementations are put in EXCEPTION_MANAGER.
>
> This is a strange answer. I don't understand why it makes it
> clean and clear. It's just unnecessarily delegating its
> implementation to an auxiliary class. If you want to see
> the class without its implementation, just use the short form.
> I would find it very cumbersome if for each class, say STRING,
> TUPLE, etc. we had to have an auxiliary class, STRING_MANAGER,
> TUPLE_MANAGER, etc. to put its implementation. I don't
> consider that as a benefit.

At least, I don't think EXCEPTION is the right place to put `catch' and `ignore'.
Something else is needed. For me, the EXCEPTION_MANAGER. Were this correct,
implementation were no bad put in EXCEPTION_MANAGER.

>
>> The reason EXCEPTION_MANAGER keeps track of ignored exceptions is that
>> ignoring
>> exceptions is an operation of types, rather than per object. So it
>> doesn't make sense
>> to have this in EXCEPTION class.
>
> What would make sense would be to implement it in class
> EXCEPTION as a once-per-type. If not supported yet, then
> we can find ways to simulate it without the need for
> EXCEPTION_MANAGER. What is not very nice with your
> implementation is that it uses ARRAYED_SET, which adds
> another unwanted dependency to the container clusters
> of EiffelBase.

ARRAYED_SET indeed introduces dependency, which could be replaced by better
implementation.

>
>> I am not too surprised at the arguments against many routines of
>> implementation in
>> EXCEPTION_MANAGER, since they could be useless for other
>> implementations. What you
>> see here is actually an implementation of the class from ISE, where we
>> try to implement
>> in Eiffel code as much as possible. The problem is we need a suitable
>> way to seperate
>> what is really needed in elks and implementations. `built-in' mechanism
>> would be
>> used when possible as Manu said. But I realized `built-in' mechanism may
>> not be sufficient,
>> because those routines will be still there.
>
> I don't think we need zillion built-in features to implement
> exceptions.

That's why I am saying built-in mechanism is not a perfect solution.

> The runtime is able to deal with manifest strings,
> manifest tuples, manifest arrays, without having to add built-in
> features, why should it be different for exceptions.

Exceptions are not as basic types as strings, arrays and tuples.
It is possible for the runtime not knowing their details.

>
>> I am not sure what you think the "a real object-oriented way" is.
>
> Where objects are not just records.
>
>> On ISE part, only those exceptions raised by the runtime has to do with
>> exception code.
>> Clients don't have to care about exception code. They can do whatever
>> they want by
>> object-oriented approach.
>> What you see so many "code" in the EXCEPTION_MANAGER is just because we
>> do the implementation in
>> Eiffel code (not creating objects in the runtime). For now,
>> the ISE runtime doesn't have to know about the detail of exception
>> object by using
>> exception code.
>
> And that's a mistake in my opinion. The runtime has to know
> about strings, arrays, tuples without exposing the implementation
> details to the programmers. I think that it should be the same
> for exceptions.

I think, as a pure object-oriented language, Eiffel doesn't need to
"hide" implementation details to the programmers, if possible. And
exceptions are not as basic types as strings, arrays and tuples. The runtime
is awkard to know any details of 20+ exception classes when no necessary.

>
>> With this, we could go without EAO in the further for
>> small systems,
>> i.e embeded, by providing a proper implementation of EXCEPTION_MANAGER.
>
> But that won't be Eiffel as specified by ECMA anymore.

I agree, you are right.

This is my penny.
Ted


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
freeelks-devel@...
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Eric Bezault]

Ted [ES] wrote:
> At least, I don't think EXCEPTION is the right place to put `catch' and `ignore'.
> Something else is needed. For me, the EXCEPTION_MANAGER.

Well, I didn't say that we should get rid of EXCEPTION_MANAGER
altogether. Just that too much importance was given to it.

> Exceptions are not as basic types as strings, arrays and tuples.

I don't share this point of view. And the fact that ECMA Eiffel
has to mention these classes is a sign of that.

> I think, as a pure object-oriented language, Eiffel doesn't need to
> "hide" implementation details to the programmers, if possible.

What should be hidden is the fact that the runtime handles
them as codes. It is possible to have Eiffel compilers whose
implementation does not handle exceptions as codes. That's
what I'm complaining about when I say that the implementation
should be hidden. Eiffel compilers should be able to use
the EXCEPTION classes even if they don't handle them internally
as codes. And it is not the business of the programmers to
know whether this Eiffel compiler handles exceptions as code
and this other compiler does not.

Now I guess I will have to wait until all promised built-in
features have been put in place and see whether exception codes
are still exposed so prominently on the Eiffel side or not.

--
Eric Bezault
mailto:ericb@...
http://www.gobosoft.com


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
freeelks-devel@...
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Ted [ES]]

I have an idea. We can have a deferred EXCEPTION_MANAGER in elks, containing all public interfaces. Have `exception_manager's as built_ins in EXCEPTIONS and EXCEPTION classes. This way we can have ISE_EXCEPTION_MANAGER as implementation in ise inherit from EXCEPTION_MANAGER.
Those built-ins create once ISE_EXCEPTION_MANAGER instances. Then too many built-ins can be avoided. What do you think?

Otherwise, `exception_of_code', `type_of_code' or similar, I would use `message_of_code', `catch_code' and `ignore_code', exported to EXCEPTIONS are still needed as interfaces in EXCEPTION_MANAGER to support EXCEPTIONS.

Ted

----- Original Message -----
From: "Eric Bezault" <ericb@...>
To: "Ted [ES]" <tedf@...>
Cc: "freeelks" <freeelks-devel@...>
Sent: Tuesday, January 22, 2008 12:45 AM
Subject: Re: [freeelks-devel] Missing exception classes in the repository

> Ted [ES] wrote:
>> At least, I don't think EXCEPTION is the right place to put `catch' and `ignore'.
>> Something else is needed. For me, the EXCEPTION_MANAGER.
>
> Well, I didn't say that we should get rid of EXCEPTION_MANAGER
> altogether. Just that too much importance was given to it.
>
>> Exceptions are not as basic types as strings, arrays and tuples.
>
> I don't share this point of view. And the fact that ECMA Eiffel
> has to mention these classes is a sign of that.
>
>> I think, as a pure object-oriented language, Eiffel doesn't need to
>> "hide" implementation details to the programmers, if possible.
>
> What should be hidden is the fact that the runtime handles
> them as codes. It is possible to have Eiffel compilers whose
> implementation does not handle exceptions as codes. That's
> what I'm complaining about when I say that the implementation
> should be hidden. Eiffel compilers should be able to use
> the EXCEPTION classes even if they don't handle them internally
> as codes. And it is not the business of the programmers to
> know whether this Eiffel compiler handles exceptions as code
> and this other compiler does not.
>
> Now I guess I will have to wait until all promised built-in
> features have been put in place and see whether exception codes
> are still exposed so prominently on the Eiffel side or not.
>
> --
> Eric Bezault
> mailto:ericb@...
> http://www.gobosoft.com
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
freeelks-devel@...
https://lists.sourceforge.net/lists/listinfo/freeelks-devel