Re: saving and restoring the error stack trace

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"



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Exception API

[Ludovic Courtès]

Hi,

"Marco Maggi" <marco.maggi-ipsu@poste.it> writes:

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

Well, test suites are one kind of application after all.  ;-)

The point is: sometimes, you need precise information about what went
wrong.  Even if you're not able to recover from the exception, you want,
at least, your application to notify its user in an intelligible way.
And you certainly don't want to parse an error message to get an idea of
what's going on (fortunately, error messages in Guile are not yet
translated!).

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

I believe the principle behind this is that exceptions should not be a
second-class API.  Thus, an exception API should be designed to be
actually used.  ;-)

The current exception mechanism _is_ useful and it conveys important
information about the exceptions (documented under the ``Handling
Errors'' node) but the semantics are not crystal-clear compared to
"regular" APIs.  Consider for instance this:

  (lambda (key . args)
    (case key
      ((system-error)
       (let ((errno (car (cadddr args)))) ;; !!!
         (if (= errno ENOENT)
             ...)
         ...))))

and this:

  (guard (c ((i/o-no-such-file-error? c)
             (let ((file (i/o-error-filename c)))
               ...)))
     ...)

I think the latter looks clearer, especially to someone not familiar
with any of those mechanisms.  And it is also probably less
error-prone.  :-)

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

Yes, maybe allowing for arbitrary objects as the `key' argument would
help.

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Exception API

[Kevin Ryde]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
>        (let ((errno (car (cadddr args)))) ;; !!!

system-error-errno helps there.  I made a few similar extracting funcs
at one time ... then found it better not to try to be too smart about
analysing errors!

>   (guard (c ((i/o-no-such-file-error? c)

I had trouble understanding the different dynamic environments
specified for that srfi-34 guard.  It looked worryingly like there
could be jumps out of the originating continuation and then back in if
there's a re-throw, which could be pretty slow with guile's
continuations.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Exception API

[Neil Jerram]

Kevin Ryde <user42@zip.com.au> writes:

> I had trouble understanding the different dynamic environments
> specified for that srfi-34 guard.  It looked worryingly like there
> could be jumps out of the originating continuation and then back in if
> there's a re-throw, which could be pretty slow with guile's
> continuations.

Yes, I had the same worry.  I don't think this is intended, though,
and none of the examples in the SRFI do anything so outlandish.
Perhaps one of us should raise this with the R6RS committee?

(My understanding is that SRFI-34 is regarded as one of the things
that will be added to R6RS, and that it is already in pretty much
final form.)

Assuming that it isn't intended, and that this is clarified in R6RS,
we shouldn't need full continuations to implement guard.

(If anyone's wondering about the catch-based implementation of guard
in srfi/srfi-34.scm, I believe it isn't quite right, but I forgot
exactly why.)

Regards,
     Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Exception API

[Ludovic Courtès]

Hi,

Kevin Ryde <user42@zip.com.au> writes:

> ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>>
>>        (let ((errno (car (cadddr args)))) ;; !!!
>
> system-error-errno helps there.  I made a few similar extracting funcs
> at one time ... then found it better not to try to be too smart about
> analysing errors!

That probably helps a bit (clarity-wise) but may still be insufficient
(since, as Neil noted, the error message itself conveys additional
information and needs to be somehow "analyzed" in order to get a full
understanding of what went wrong).

>>   (guard (c ((i/o-no-such-file-error? c)
>
> I had trouble understanding the different dynamic environments
> specified for that srfi-34 guard.

Just to make it clear: I was only trying to illustrate the clarity
offered by SRFI-3[56], not arguing about SRFI-34.

Thanks,
Ludovic.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user