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>
- Limiting the number of messages