Re: [eclipse-clp-users] Java error messages

Gregory Harman wrote:
> 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.
> 

There are at least two issues related to getting the error id from an
exception on the executing of an ECLiPSe RPC goal:

1) This information is not available to the RPC goal. This is because
the error handling for built-ins in ECLiPSe is an event based model --
an error raise an error event for the error, which is handled by the
error handler defined for that error. The default handlers generally
prints a message to the error stream, and then aborts the execution by
calling abort/0 -- this is what is returned by the RPC code. So in order
to know what the actual error that caused the abort is, you need to
define your own error handler(s) for the error(s) as I suggested
previously, which can then pass the information such as the error id to
the Java side.

2) Errors are raised by ECliPSe builtins. Normally your RPC would be
executing ECLiPSe code you wrote, which is likely to have many builtins.
It is not of much interest to tell the Java side that some builtin in
your ECliPSe code is causing an error -- your Java code should not need
to know the details of your ECLiPSe code. Instead, you should return
information that relates to the RPC goal you called (e.g. that some
argument in it is incorrect). To do this, you need to write some ECLiPSe
code in the goal called by RPC to generate the information you need. You
can use block/3,exit_block/1 to implement this (if you need to throw an
error somewhere deep inside your goal). This is what I meant by error
handling generating information useful to your Java side in my last post.

> 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.
> 

For debugging purposes, the error message for a builtin is not
normally sufficient for you to determine the problem. Firstly, there is
no information where in the source the builtin is; secondly, it may
be difficult to relate the variables in the printed error message to the
variables in your RPC, even assuming they occur as an argument in your 
RPC. Of course, if your RPC goal is simple enough, you may be able to 
figure out the problem from the error message, but if your RPC goal is 
that simple, it is probably not worth executing it using ECLiPSe rather 
than implementing the equivalent in Java.

As I said, for development, you should try to develop your ECLiPSe code
independently of the Java side first. You can generate test cases
manually during development -- I assume this should be possible?

Hopefully the above will remove most errors, but of course errors are
still possible with your `real' data. This is why I suggested
lib(remote_tools), which was designed specifically for this purpose.
There is no need for any `cut and paste' as you suggest, because you can
  use the RPC goal that is executed. The remote tools has the same 
development tool suite as TkECLiPSe (the same code is used to implement 
both), and which is also implemented by Saros (Saros uses the same 
ECLiPSe side code for the development suite, and reimplements the Java 
side code, which is basically GUI related). You need to initialise your 
application to use remote_tools, and provide some way for you to get 
control for the tools to allow you to set spy/break points etc, which 
can be done via RPC.

Cheers,

Kish

-- 
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.