Subject: Re: reporting message send errors at run-time
From: Craig Chambers (chambers@cs.washington.edu)
Date: Thu Mar 02 2000 - 13:01:49 PST
Option 3 is my preference. Option 2 and 3 are the same as far as the
dispatcher is concerned; option 3 just includes a more informative error
method. The GFs which have ambiguously defined methods are rare, so the
overhead relative to option 1 should be low. Message not understood
errors are frequent in dynamically typed languages, so they should be
handled efficiently. Statically typed languages should have neither
kind of error, so the issue shouldn't arise.
I implemented option 2 in my protype Vortex implementation, since I
didn't care about the quality of error messages in my prototype, and I
could share a single global ambiguous-msg error function across all
dispatchers.
-- Craig Chambers
Mayur Naik wrote:
>
> Hello!
>
> Could you please tell me which of the following is the most suitable way to
> report at *RUN-TIME* that an MSA method does not exist for a message send:
>
> 1. Report all errors by a single error method:
>
> msg-err(msg-name n, run-time-class-arg-list l)
> {
> print("MSA method does not exist for message %s(%s)", n, l)
> }
>
> 2. Report 'message not understood' and 'message ambiguous' errors
> separately:
>
> msg-not-understood-err(msg-name n, run-time-class-arg-list l)
> {
> print("message %s(%s) is not understood", n, l)
> }
>
> msg-ambiguous-err(msg-name n, run-time-class-arg-list l)
> {
> print("message %s(%s) is ambiguous", n, l)
> }
>
> 3. Same as (2) above except that the set of applicable methods is also
> passed as an argument to msg-ambiguous-err and printed.
>
> Note that as the verbosity in error reporting increases, the efficiency of
> the dispatcher decreases, since the error reporting methods themselves
> become distinct targets, making the multi-way switch bigger and slower.
>
> Thanks.
>
> -- Mayur
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
This archive was generated by hypermail 2b25 : Tue Oct 03 2000 - 15:21:23 PDT