Re: saving and restoring the error stack trace

[Marco Maggi]

"Neil Jerram" wrote:
> Out of interest, though, what changes would you like to the
> presentation?

If you are referring to  the documentation draft: I think it
is fine. If you are referring to the stack trace I posted: I
would like it  to be the same as for  a 'common' error: with
the section

> <unnamed port>: In procedure gsl-ode-evolve in expression
> (gsl-p-ode-evolve ode initial-indep-value ...):
> <unnamed port>: my error message 1 and 2

displayed at  the bottom, below  all the stack frames.  I do
not think that it is easy to do: I obtain the stack trace by
recording the stack  at the moment of error,  and then using
the  lower section  of  it  as part  of  the error  message.
Splitting a stack and appending a section to another seems a
dirty  thing (I  do not  know  how a  stack is  implemented,
though).

"Neil Jerram" wrote:

>do you think  that the way my Emacs  interface displays the
>stack is better or worse than this?
>http://www.ossau.uklinux.net/guile/debugging-demo/shot2.html

I  dunno. It has  a completely  different purpose.  Nice one
that there is a stepping debugger, though.

"Neil Jerram" wrote:
>"Marco Maggi" wrote:
>> and that the args content is not explicitly documented
>> even if its content is well defined in 'scm_error_scm()':
>>
>>   scm_ithrow (key,
>>         scm_list_4 (subr, message, args, data), 1);
>
>Yes, here I completely agree with you.

I  do not  have  enough experience  to  be authoritative  on
exception handling. :)

I want  to make clear that  the 'args' I am  referring to is
the  'args'  handed  to  the  'scm_t_catch_handler  handler'
function, parameter of  'scm_c_catch()'. This 'args' ends up
being the:

  scm_list_4 (subr, message, args, data)

list;  this  value is  exception  independent.  I want  this
'args'  created   by  'scm_error_scm()'  to   be  officially
documented  so  that  there   is  a  constraint  on  keeping
compatibility. :) I do not  think that this list needs to be
changed;  maybe a  helper function  that formats  the string
could be useful, so that one can avoid putting:

  scm_simple_format(s_port, s_message,
    (scm_is_eq(SCM_BOOL_F, s_args)? SCM_EOL : s_args));

in the code, as I have done, to build the message.


"Ludovic Courts" wrote:
>Indeed,  this exception  model is  not very  convenient.  In
>some cases,  it's even hardly usable, as  examplified by the
>`test-suite/lib.scm'   hacks  (use   of  regexps   to  parse
>exception messages and determine their meaning...).

But applications and test suites are different scenarios.

"Ludovic Courts" wrote:
>Ideally, Guile should  use some SRFI-3[56]-like mechanism to
>represent exceptions.

SRFI-35 defines  a complex value,  maybe too complex.  It is
not  clear to me  if a  fine-grained hierarchy  of exception
descriptors can really improve the quality of the code.

There   are   two   classes   of   exceptions:   logic   and
runtime. Logic  are the problems that I  should have removed
at debugging time, I do not think that it is possible to try
to recover from those.  Runtime are state synchronisations.

How can the application recover from a state synchronisation
exception?   One  aborts   the   transaction  and/or   frees
asynchronous resources allocated for the operation. Is there
a significant  number of real-world  cases in which  one can
retry the operation without aborting/freeing?

Should  it  be possible  to  do  something without  breaking
compatibility  by generalising  the 'key'  argument  and use
upon it a generalised version of 'equal?'?




--
Marco Maggi

"They say jump!, you say how high?"
Rage Against the Machine - "Bullet in the Head"