Thanks for the response, Kish. I'm interested in both error-handling and debugging from Java. In the end the entire application needs comprehensive error-handling and reporting, and that will need to be from Java since it's the primary language the application is written in. (Actually Clojure, but let's call it Java to avoid a whole extra layer of complexity! :-) In my particular case, it would be fine to handle the error from Java - I can use the information to re-generate the erroneous goal. Regarding debugging, getting good messages straight in Java would be a real time-saver; the application generates the goals (actually the variables in those goals) that get executed by ECLiPSe, so while I can copy/paste the generated value into e.g. Saros, that's an extra step which slows down debugging. As I mentioned in my reply to Joachim a couple minutes ago, I still feel that it would be more "proper" for the Java interface to include an error message in the Throw, but it is what it is so I'll look into ELCiPSe-side error handlers and having Java listen on stderr as you suggest. best, Greg On Mar 3, 2009, at 8:29 PM, Kish Shen wrote: > Hi Gregory, > > From your message, I am not sure if you want to debug your ECLiPSe > code in Java, or if it is to write error handling code for ECLiPSe > in Java. > > In both cases, I think it is best to try to do as much in ECLiPSe > rather than Java. ECLiPSe is a full programming language, so in > general it is much better to do development and handle programming > tasks in it. On the other hand, the Java interface (and indeed the > other interfaces of ECLiPSe to external languages) are not really > designed for doing ECLiPSe programming development through the > interface. > > For debugging, if possible, you should try and develop your ECLiPSe > code using ECliPSe's development environment (Saros, as suggested by > Paul, or TkECLiPSe) before connecting it to Java. If this is not > possible, and you must debug your ECLiPSe code while running it > through Java, you can use lib(remote_tools) to connect the ECLiPSe > development tools (used in TkECLiPSe and also Saros) to any process > running ECLiPSe code, even if you are using RemoteECLiPSe and the > ECLiPSe process is running on a different machine from your Java > code (and your remote tool -- you do need to have ECLiPSe on your > local machine so that you can run the remote tools there). > > For writing error handling code for ECLiPSe, this is best done in > ECLiPSe itself. By the time the execution of an ECLiPSe goal returns > to Java with an exception, it is rather late to handle the error (in > addition to the lack of facilities to do so). Error handling in > ECLiPSe is discussed in the Events and Interrupts chapter of the > User manual (section 13.2 in the current version): > > http://www.eclipse-clp.org/doc/userman/umsroot072.html > > One way of handling errors would be to write your own error handlers > for the errors you want to handle, and in your error handler, you > can communicate with Java, giving your Java code the information you > need on the Java side about the error. > > The default ECLiPSe error handlers should print their error messages > in the ECLiPSe error stream. Depending on how you set up your > ECLiPSe peer, the error stream can either be connected to your > JVM's stderr, or you can connect it to your own FromECLiPSeQueue, > this will allow you to see the error message on the Java side, if > you don't write your own error handling code. > > Hope the above helps, > > Kish > > Gregory Harman wrote: >> Hi all, >> I'm fairly new to ECLiPSe, and am planning on using it as a >> supplement to a Java codebase. I've gotten basic communication >> between Java and ECLiPSe working via the parctechnologies library, >> but I'm struggling a bit with the error handling: when I execute a >> goal that causes an ECLiPSe error, I get a >> com.parctechnologies.eclipse.Throw returned to my Java class (as I >> should, according to the embedding documentation), but there is no >> error message associated with that Throw to help me debug. How can >> I coerce the system into giving something more to work with than >> just "there was an error"? >> Thanks for any pointers. >> -Greg >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San >> Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the >> Enterprise >> -Strategies to boost innovation and cut costs with open source >> participation >> -Receive a $600 discount off the registration fee with the source >> code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> ECLiPSe-CLP-Users mailing list >> ECLiPSe-CLP-Users_at_lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/eclipse-clp-users > > > -- > This e-mail may contain confidential and privileged material for the > sole use of the intended recipient. Any review, use, distribution or > disclosure by others is strictly prohibited. If you are not the > intended > recipient (or authorized to receive for the recipient), please contact > the sender by reply e-mail and delete all copies of this message. > Cisco Systems Limited (Company Number: 02558939), is registered in > England and Wales with its registered office at 1 Callaghan Square, > Cardiff, South Glamorgan CF10 5BT.Received on Wed Mar 04 2009 - 05:29:18 CET
This archive was generated by hypermail 2.2.0 : Thu Feb 02 2012 - 02:31:58 CET