In my experience, there are two different sorts of exceptions:
1. Those that one might want to handle: Errors on invalid input of different sorts, the more common I/O errors, etc. 2. Errors that one typically never wants to handle: Argument errors, indexing errors, etc.
It's those in the first category that needs typing, those in the second does not. Also, the errors in the first category are way fewer.
In fact, the vast majority of all error() calls in Pike and Pike_error() calls in C fall into the second category. I think those two functions are perfectly fine to use in such cases. They're lots easier to use than typed error objects, especially on the C level. (Creating typed errors in C is a real pain. It could probably be improved a bit by better support functions, but it can never get as simple as a Pike_error call.)
I therefore think that the right approach is to fix typing for the fairly few errors where there's a need for it and simply leave the rest untyped. That's done module-by-module and error-by-error, of course.
I don't believe (anymore) in a fancy error hierarchy that tries to encompass both categories. I've simply never felt any use for that.
So imo both error() and Pike_error() should (nay, must) stay, but they could be changed to throw Error.Generic objects instead.
i'd be happy to create new error types for the errors that my code is currently handling.
I say don't sweat it. Converting all the odd errors of the second category above is probably just a waste of time.
the reason for changing error() to return an error object is to be sure that any error handling code can be sure to only have error objects to deal with. /.../
Yep, that would afaics be the only reason for doing it (not implying that it's an insignificant reason). But also remember that anywhere where you aren't sure to deal only with newer code, you must play safe and assume that catch() still might return an array (or anything else, for that matter; well written catch code should never fail itself on an odd error type since that'd clobber the real error).
hmm, (object_program(error)==MySpecialError) appears to work and not complain if the error is an array.
Strange. I consider that a bug, actually. Anyway, that way of testing an error isn't very good.