#2 Client_Error

[troels knak-nielsen]

Using Client_Error instead of just plain Error means that
various debug-info (esp. linenumber and filename) isn't
available.

[Harry Fuecks]

Logged In: YES
user_id=569780

Hadn't considered that.

Would like to keep the Client_Error if possible to allow
people to centralize error handling should they choose,
while still being able to spot the different error types.
Also planning to add standard error codes (rather than
inheritance) to allow specific errors to be identified.

Will see what I can do to repackage information provided by
Error, unless anyone has better ideas.

[troels knak-nielsen]

Logged In: YES
user_id=54994

how about using a decorator for this purpose ? something like
the following :

function Client_Error(e)
{
e.bogus = "foo";
return e;
}

...

if ( !success ) {
throw Client_Error(new Error("Unable to comply."))
}

[Harry Fuecks]

Logged In: YES
user_id=569780

Thanks for the tip. Will try that out when I get a moment -
sounds like a good approach.

[Harry Fuecks]

Logged In: YES
user_id=569780

Well the error handling has been overhauled - now doing it
as you suggested plus standardized the error codes. Actually
in most cases there isn't a line number to report - many of
the errors are things like the remote server returning an
invalid HTTP status code.

What I'm wondering about now is the way errors are handled
in the generated clients as described here:
http://xmlrpccom.sourceforge.net/scriptserver/scriptserver/docs/scriptserverse3.html#x8-290003.4

Basically the generated client, right now, handles
client_errors, server_errors and application_errors
differently. In theory this makes it easier for people using
the clients, avoiding the need for switches to work out what
type of error they have but in practice I'm feeling it's
just code bloat and tempted to scrap it again.

Would be very interested to hear you opinions.