chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] handle "unbound variable" exception for undefined proced


From: Shawn Rutledge
Subject: [Chicken-users] handle "unbound variable" exception for undefined procedures?
Date: Fri, 19 Dec 2008 00:06:23 -0700

This is probably a pretty far-out idea but I wonder if it's possible.

I'm working on the concept of proxy objects representing remote
tinyclos objects.  After figuring out how to create the proxy when one
side attempts to "send" an object to the other side, next problem is
how to arrange for all relevant generic functions to be implemented
for the proxies, to send the remote method invocation.  I can have the
receiver find out what methods are implemented for a given class, the
first time it notices that the class exists, but then methods could
still be added later.  It would be cool if the proxy method
implementations could be defined on an as-needed basis.

Suppose r is a proxy object and bangarang is a method defined on the
other side of the link:

(handle-exceptions exn
                     (begin
                       (display "Went wrong: ")
                       (display
                        ((condition-property-accessor 'exn 'message) exn))
                       (newline))
(bangarang r))
Went wrong: unbound variable
Warning: the following toplevel variables are referenced but unbound:
  bangarang

I could catch the unbound variable exception specifically right? but I
guess it would involve a string compare (string=?
((condition-property-accessor 'exn 'message) exn) "unbound variable")
which is not efficient.  And then what?  "All error-exceptions (of the
kind exn) are non-continuable."  I'd be wanting to do another remote
query to confirm that the unbound symbol is really an applicable
method, bind it locally to a procedure that will call the remote
method, and then call it again with the same arguments.  Next time
that same method is called, it's already bound, so this
exception-catching only happens once, and would be a way to achieve
the lazy binding.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]