Classes vs. Exceptions

[andreynech]

Hi,

Taking in account the idea of making Slice more simple as CORBA IDL by removing unnecessary and redundant featrues I would like to ask about the motivations to introduce Exceptions as a separate entity. Would not it be possible to allow throwing any structures or classes? I understand that some languages (like Java) expose additional requirements to the type to make it possible to throw it (Throwable) but maybe Slice compiler could be smart enough to generate corresponding code if necessary? I am just curious and would be glad if somebody could comment on this topic.

Thank you,
Andrey.

[michi]

Originally posted by andreynech
Hi,

Taking in account the idea of making Slice more simple as CORBA IDL by removing unnecessary and redundant featrues I would like to ask about the motivations to introduce Exceptions as a separate entity. Would not it be possible to allow throwing any structures or classes? I understand that some languages (like Java) expose additional requirements to the type to make it possible to throw it (Throwable) but maybe Slice compiler could be smart enough to generate corresponding code if necessary? I am just curious and would be glad if somebody could comment on this topic.

Thank you,
Andrey.

Yes, we considered doing this at length. In fact, I was one of the major proponents of that. In the end we decided against it. The reason is that not all languages permit you to throw arbitrary types, such as Python and Java. Yes, we could have packed non-exception types into a language-native exception type for such languages, but then the simplicity is lost again at the language level.

We went through similar arguments with classes and structs: why have inheritance on classes but not on structs? The reasoning here was that plain structs are more efficient and can be marshaled with less overhead and mapped to a language-native plain struct, whereas, for classes, we have more overhead due to the need to deal with derivation. In the end, retaining plain structs as a separate type was seen as the right compromise.

Cheers,

Michi.

[marc]

I'm afraid it's more languages than only Java.

For Java, we would basically have to make every class throwable, because every class might potentially be an exception. For other languages, it would be even worse. For example, exceptions in Python are separate from the normal type system.

In addition, I believe that a separate exception type also provides more clarity to Slice code.

[andreynech]

Thank you all very much for the explanations.

Andrey.

[dthomson]

Marc and Michi,

Originally posted by Michi
The reason is that not all languages permit you to throw arbitrary types, such as Python and Java.

Originally posted by marc
For example, exceptions in Python are separate from the normal type system.

This is news to me, and I've done a little Python What do you mean? I can throw any object as an exception in Python. Including built-in types like strings and integers.

BTW I agree with your decision with regards to keeping exceptions a separate type in Slice.

Here's some examples:

#!/usr/bin/env python

# Define an exception class.
# Note that there's nothing special about it!

class SomeException:
    def __init__(self, msg, severity):
        """Create an instance of the exception class"""
        
        self.msg = msg
        self.severity = severity

    def __str__(self):
        """Convert the exception to a string"""

        return ("SomeException (msg:%s, severity: %d)" %
                  (self.msg, self.severity))

# Throw an instance of the new class

try:
    
    raise SomeException('Bad craziness', 42)

except SomeException, e:
    
    print 'Caught:', e

[marc]

We worked on a project called "Pyce" (Ice for Python) some time ago. At this time, Ice still allowed "everything to be an exception", and we had a lot of trouble implementing this model with the Python/C API.

However, it is quite possible that we simply did something wrong. We are no Python gurus. In any case, I can't remember the details, it's too long ago, and Pyce is now on hold.

If someone with more Python experience wants to pick up Pyce, we would of course be more than happy to help whereever we can Ice for Python would definitely be very cool.

[dthomson]

Originally posted by marc
We worked on a project called "Pyce" (Ice for Python) some time ago. At this time, Ice still allowed "everything to be an exception", and we had a lot of trouble implementing this model with the Python/C API.

That's quite a reasonable excuse, actually. The Python/C API is under-documented, especially when it comes to implementing true Python classes in C.

Implementing simple functions is fine ... but the rules for implementing new classes in C only existed in skeleton form in the documentation last time I looked. One of my plans is to figure it out and update the documentation. One of these days ...

However, it is quite possible that we simply did something wrong. We are no Python gurus. In any case, I can't remember the details, it's too long ago, and Pyce is now on hold

It certainly should have worked. That said, there may also have been some bizarre bug in the Python/C API layer causing extension classes not to be implemented properly so that they can't be thrown. I will definitely try this when I get the chance, and if it doesn't work raise it with the Python dev team.

If someone with more Python experience wants to pick up Pyce, we would of course be more than happy to help whereever we can Ice for Python would definitely be very cool.

If that's a hint, I'm way, way, way, too busy! I'm supporting two scripting ORBs in my own time at the moment, and that is too much I'm afraid. And I'm supposed to be having a break! So, much as I'd like to, I can't right now.

[marlowa]

Originally posted by marc
We worked on a project called "Pyce" (Ice for Python)

If this project ever gets resurrected you could call it 'CrushedIce'. Groan!

-Andrew