Re: Stop on message?
- To: mathgroup at smc.vnet.net
- Subject: [mg126707] Re: Stop on message?
- From: Leonid Shifrin <lshifr at gmail.com>
- Date: Fri, 1 Jun 2012 05:18:22 -0400 (EDT)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- References: <201205260911.FAA07083@smc.vnet.net>
Hi Christoph, Szabolcs makes a good point. I just want to add to that, that in my view, messages are absolutely fundamental for functions you give to others (and also use yourself), because they enforce good abstractions and reduce complexity. The point is that when the user provides wrong arguments or runs into some internal error of your function, they could not care less about the inner details responsible for that. If you don't catch and report these cases, this falls through to the incorrect usage of functions on which your function is based (and this is if your user is lucky), and ends up with a bunch of cryptic error messages from those more fundamental functions (perhaps built-in functions). What this means is that your function does not fully implement the abstraction it is supposed to, and that abstraction "leaks" to a deeper level on which it is based. This violates some of the main principles of good software design, such as information hiding. And often, you won't get error messages from those core functions at all - you just get the silent but wrong behavior. Carefully caught errors and corresponding error messages in your function insulate your abstraction from the ones on which it is built, and makes it more robust and easier to use. In large projects, this is one of the main tools to manage the complexity, and good error messages can ultimately make a difference between a project which can be realistically coded and debugged in a given amount of time, and the one which can not. If you create your code base entirely from scratch and either don't use other libraries / code or are very confident in your debugging capabilities, this may be different. There are programming techniques which may largely eliminate the need for error messages, since all code will be written in a self-documenting and "self-debugging" style. But this is a special situation, and in Mathematica you actually never start from scratch, since Mathematica is a huge system with a very rich language, and big parts of it are written in itself. Cheers, Leonid On Thu, May 31, 2012 at 9:49 AM, Szabolcs Horv=E1t <szhorvat at gmail.com> wrote: > Hello Christoph, > > I think it all comes down to whether you are writing a self-contained > GUI application or you're writing a function. > > The only GUI application I wrote was an image uploader: > > > http://meta.mathematica.stackexchange.com/questions/5/can-i-easily-post-images-to-this-site-directly-from-mathematica-yes > > It does issue messages (to the console) when things go wrong, but I'll > be ready to admit that these are more of an annoyance than useful for > the end user. The only reason I left them in is so that I can > diagnose and fix problems more easily (people can tell me about the > messages when something went wrong). > > On 30 May 2012 09:48, Christoph Lhotka <christoph.lhotka at fundp.ac.be> > wrote: > > Hello, > > > > thank you for your detailed answer. The two examples > > you mention are in good agreement with my argumentation: > > > > A message marks an error or a warning and should > > be taken as a motivation to change the code until > > those messages disappear: > > > > Example 1: > > > > > > Solve[-26.81 == 194 k + k*l*32.9 && 22.2 == -74 k + k*l*59.7, {k,l}] > > > > The "error" is that one uses a function which is designed to > > return an exact solution for an inexact equation. The solution to > > the "message problem" is not (!) to wrap Quiet[] around the code > > but to use the right function for the right purpose, which in that > > case is NSolve: > > > > NSolve[-26.81 == 194 k + k*l*32.9 && 22.2 == -74 k + k*l*59.7, {k, l}] > > > > No message is generated any more. > > > > > > Example 2: > > > > > > FindMinimum[x^2/2 + Cos[x], {x, 1}] > > > > The essential part of the message, which is returned is the sentence: > > > > "...The line search decreased the step size to within the tolerance > > specified by AccuracyGoal and PrecisionGoal but was unable to find a > > sufficient decrease in the function...." > > > > Which just tells us that the function FindMinimum was unable to do the > job, > > so the result is questionable. Fortunately, Mathematica gives you a hint > how > > to deal with the issue: > > > > FindMinimum[x^2/2 + Cos[x], {x, 1}, WorkingPrecision -> 24] > > > > Again, no warning message is produced. > > > > > > I think, that in my over 10 years of Mathematica experience I always took > > the right choice to 1) be sure that any function I used or developed does > > not produce a warning message before 2) I use them to implement another > > function on their basis. > > > > I also agree that the discussion maybe unessential for the interactive > user. > > > > Best, > > > > Christoph > > > > > > > > On 05/29/2012 06:22 PM, Szabolcs Horv=C3=A1t wrote: > >> > >> Hi Christoph, > >> > >> Mathematica is used interactive most of the time. =C2 It's very > different > >> from most other programming languages in this respect. =C2 In C, or even > >> in Python (which has an interactive shell), most of the time people 1. > >> first write the program and debug it 2. then they package it up and > >> give it to the user to run. =C2 In Mathematica we typically don't write > >> stand-alone programs. =C2 The system is usually used interactive, and > the > >> most "packaged up" things are functions meant to be used by end-users. > >> =C2 In other words: even the user is a programmer. > >> > >> When you make a standalone program like a text editor, your users > >> shouldn't see any internal warnings/errors (on Linux these messages > >> are often printed to the console on they're pretty uninformative to > >> me, as a user, 95% of the time). =C2 When you make a function for > another > >> programmer to use, there are many reasons to keep those > >> errors/warning/informative messages. > >> > >> Messages are one of the way functions communicate with users. =C2 Here's > >> one example: > >> > >> > >> > http://mathematica.stackexchange.com/questions/6055/how-to-get-rid-of-warnings-when-using-solve-on-an-equation-with-inexact-coeffici/12 > >> > >> The input Solve[-26.81 == 194 k + k*l*32.9&& =C2 22.2 == -74k+ k*l* > >> > >> 59.7, {k, l}] issued a warning message, prompting the user to check > >> the answer. > >> > >> Another example is FindMinimum[x^2/2 + Cos[x], {x, 1}] (from the > >> docs), where an answer *is* returned, but there's also a warning that > >> it might be incorrect. =C2 Version 5's General::spell messages are yet > >> another example. > >> > >> There's no "writing" and "debugging" step here. =C2 This is the usual > way > >> to use the system. =C2 Solve and FindMinimum are high level functions > >> which are probably more commonly typed than used as parts of other > >> functions. =C2 These examples could occur in any usual interactive > >> session of Mathematica. > >> > >> So, to sum up: > >> > >> Usually there's no "development phase" when you work with Mathematica. > >> =C2 If there is, you're probably developing a "library" for users who > are > >> going to use it to "program" (actually just use the system > >> interactively), and therefore they'll need messages again. > >> > >> I hope this clears it up. > >> > >> On 29 May 2012 18:07, Christoph Lhotka<christoph.lhotka at fundp.ac.be> > >> =C2 wrote: > >>> > >>> Hi, > >>> > >>> =C2 in my opinion messages in Mathematica are generated during the > >>> evaluation > >>> process to give > >>> some kind of "meta"-information about 1) what is going wrong or 2) what > >>> you > >>> need to know > >>> to check by yourself to know of the returned result is correct. > >>> > >>> I would like to compare this information with the concepts of "errors" > >>> and > >>> "warnings" produced > >>> by a compiler during the process to produce a program. > >>> > >>> Seeing "Mathematica messages" in this flavour any input which produces > a > >>> message should be > >>> seen as wrong or not working properly and therefore be modified as long > >>> as > >>> there are no > >>> messages left at all. > >>> > >>> I therefore do not see a reason yet why I should use messages outside > the > >>> development > >>> phase of a project. > >>> > >>> Can you provide me with one? > >>> > >>> Thanks, > >>> > >>> Christoph > >>> > >>> > >>> > >>> > >>> > >>> On 05/29/2012 11:47 AM, Szabolcs Horv=C3=A1t wrote: > >>>> > >>>> There were two replies suggesting to use Check[] to abort evaluation > >>>> when a message is generated. > >>>> > >>>> Note that while Check does return a different result if a message was > >>>> generated, it does not actually interrupt evaluation (it completed the > >>>> evaluation of 'expr'). > >>>> > >>>> See here for an example: > >>>> > >>>> > >>>> > >>>> > http://mathematica.stackexchange.com/questions/5534/check-does-not-interrupt-evaluation-of-the-expression-when-a-message-is-emitted > >>>> > >>>> Please see here for a method that will reliably abort immediately > when a > >>>> message is generated. > >>>> > >>>> > >>>> > >>>> > http://mathematica.stackexchange.com/questions/1512/how-to-abort-on-any-message-generated > >>>> > >>>> On 2012.05.27. 10:40, Sseziwa Mukasa wrote: > >>>>> > >>>>> Check[expr,Return[]] > >>>>> > >>>>> On May 26, 2012, at 5:11 AM, Ralph Dratman<ralph.dratman at gmail.com> > >>>>> wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Is there a simple way to get Mathematica to stop evaluating (like > >>>>>> Interrupt) whenever a message is issued? > >>>>>> > >>>>>> I realize the debugger has that feature, but I would prefer not to > use > >>>>>> it in this case. > >>>>>> > >>>>>> Thank you. > >>>>>> > >>>>>> Ralph Dratman > >>>>>> > > > >