Re: Parser Size

David Crawshaw <[email protected]> writes:
> Do you have any long term plans for error handling?

My only solid plan is to do something better and more consistent than
what we're doing now ;)

One thing I'd like to do is have exceptions thrown inside a read trap
get propagated out to the 'caller' of the read trap, but exceptions
thrown in a write trap are written into the log and then dropped on
the floor.  The general theory here is to proceed whenever possible.
If an exception is thrown in a read trap, you can't continue because
you don't know what to return to the caller.

As for how builtin functions (org.xwt.XWT.*) should behave when passed
invalid arguments, I'm not sure.  The two possibilities are to log an
error and return null, or else to throw an exception.

Also, I have no idea what object to throw when we do throw exceptions.
A String?  An XML-RPC style {faultCode,faultString}?  Java does the
Right Thing by having an inheritance tree and strong
typing... unfortunately JS is weakly typed.

Perhaps exceptions should be String's in the form

  "super:sub:subsub - humanreadable"

For example

  throw "IOException:HTTPException:404 - Not Found"

    or

  throw "IOException:DNSException:HostNotFound - couldn't resolve www.yourmom.com"

This lets catch{} blocks do the equivalent of 'instanceof' by using
the String.startsWith() function.  Stripping out the human readable
message (in order to present it to the user) is also easy:
substring(indexOf('-')+1).

Just some random thoughts.

  - a

-- 
Palladium / TCPA violates Asimov's Three Laws:
http://yro.slashdot.org/comments.pl?sid=60943&cid=5740626

_______________________________________________
http://lists.xwt.org/listinfo/dev