would it make sense to have catch always return an error object? or respectively, change throw to always create an object out of the arguments it receives?
I don't think that'd be worth the compatibility hassle. I've seen code throwing plain strings internally and catch them with a stringp() test. (I don't recommend that kind of stunt, but in some applications where errors are thrown very frequently it could be justifiable.)
you mean it should throw if i use object_program() on an array?
Yes, or on anything else that isn't an undestructed object.
(objectp(error) && error->is_my_special_error)
This is the kind I prefer since it gives the thrower complete control over thrown error object: It's possible to combine error classes, and to construct an own error class that not even inherits the original one (which might be difficult in dynamically compiled environments). It also allows quick-and-dirty code that simply defines a constant to trig a specific catch somewhere, without having to implement an entirely-fledged compatible error object.
unhandled errors should definetly be rethrown automaticly.
Yes, definitely. That's why it's important to provide decent expressive power in the catch clause tests. You don't want to force people to resort to stuff like this:
try {...} catch (MyError err) { if (err->failure_pos >= 4711) { ... } else throw (err); }