[Date Index] [Thread Index] [Author Index]

Re: Re: Limiting the number of messages

• To: mathgroup at smc.vnet.net
• Subject: [mg103842] Re: [mg103837] Re: [mg103810] Limiting the number of messages
• From: "David Park" <djmpark at comcast.net>
• Date: Fri, 9 Oct 2009 07:14:54 -0400 (EDT)
• References: <200910071102.HAA00467@smc.vnet.net> <30831739.1255004811326.JavaMail.root@n11>

There is a quick and dirty method that isn't too bad in the case that bad
input data just ruins the calculation. Just issue a message and Abort. I
think this always shuts down any containing expression. Example:

foo1::mistake = 
  "Input to the foo1 routine must be integer between 1 and 3. You \
passed ``";
foo1[i_Integer] := 
 If[1 <= i <= 3, i^2, Message[foo1::mistake, i]; Abort[]]
foo2[x_] := x + foo1[x]

foo2[2]
6

foo2[x]
x + foo1[x]

foo2[6]
$Aborted   (* with a message *)


David Park
djmpark at comcast.net
http://home.comcast.net/~djmpark/  



From: Leonid Shifrin [mailto:lshifr at gmail.com] 

Hi Sean,

To my mind, usage messages are needed mostly for those functions that you
are exporting to the user of your functionality. I beleive that the software
model where user's input checks are relegated to internal functions is
seriously flawed. For internal layers of a program (that is, for a
developer), I would use exceptions and stack traces, catching them in the
outer layers, possibly logging them,  and issuing error messages to the user
(possibly with a request for a bug report). At the end, errors happening
deep inside a program would indicate to me some flaw in the program rather
than in the user's input (which, I believe, should be checked by the public
functions exported to the user as properly and completely as possible), and
the user can  not be  supposed to examine a source (which may be even not
available to him/her) to find the reason for the wrong behavior.

I don't know any good way of making the procedure stop or abort its
evaluation upon some condition depending on evaluation of sub-procedures,
simply because the control has already been passed to sub-procedures
(perhaps  unless you use some form of non-local flow of control, such as
programming in continuation-passing style, which you probably don't).
Besides, a universal rule of aborting a function after some fixed number of
issued  error  messages is a rather ad hoc procedure - if you use stateful
programming (at least in part), your program  / system may end up in an
illegal state. However, exceptions (which also represent non-local control
flow) issued by sub-procedures in a controlled way, may effectively allow
you to do a similar thing to what you want.

Sorry if I wasn't exactly helpful.

Regards,
Leonid



On Wed, Oct 7, 2009 at 3:02 PM, Sean McConnell <
smcconne at physi.uni-heidelberg.de> wrote:

> Hi,
>
> I'm creating a program with procedures that often depend on
> sub-procedures. Many times I allow the sub-procedures to do the input
> checking, so I don't have to write a the same error trapping conditions
> and messages for each level of the program. The problem is however that
> although the 'input checking' is passed on to a sub-procedure, the main
> procedure continues to attempt to evaluate, and can usually return a
> very long list of error messages whilst it foolishly attempting to
> evaluate with improperly input variables.
>
> I would like to know how to make a procedure abort its evaluation after
> say 3 or so messages, and simply return the name of the procedure and
> the variables (as happens when you use /; for conditionals). I have
> tried the use of Check[], and although it checks for messages, it will
> only return what is typed in to the space for a second argument (eg:
> Check[f[a], "problem"] will return simply "problem"), I would like to be
> able to tell the user how they have screwed up.
>
> Many thanks,
>
> Sean McConnell.
>
>
>

• References:
  • Limiting the number of messages
    • From: Sean McConnell <smcconne@physi.uni-heidelberg.de>