On Wed, May 30, 2007 at 05:45:01PM +0000, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
So imo both error() and Pike_error() should (nay, must) stay, but they could be changed to throw Error.Generic objects instead.
ok.
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.
i did not intend to do that. i only plan to change the errors that i need to handle in my code.
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).
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?
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.
you mean it should throw if i use object_program() on an array? (actually, i think it should return an Array class, but that's another topic).
what is a better way to test the error type? (objectp(error) && error->error_type==MySpecialError.error_type) or (objectp(error) && error->is_my_special_error) ?
for some reason i'd like to avoid the use of objectp() but i guess it is not any worse than using object_program()
greetings, martin.