Stop on message?

[Ralph Dratman]

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

[Gerry Flanagan]

Look at Check. The failure expression can be Abort[]

[Sseziwa Mukasa]

Check[expr,Return[]]

[Ralph Dratman]

Thank you, Szabolcs. That is most helpful.

This feature should be readily available to all Mathematica users.
Moreover, it should be the default behavior.

Here we have a good example of a very simple change that could
significantly smooth the road for new users.

I often think is a real pity, and largely unnecessary, that
Mathematica has to be so hard for newcomers to master. Certainly the
concepts and vocabulary of Mathematica's unique language are likely to
remain a challenge, but there is no reason to make the tyro's life
even more difficult by having the program freeze up just when she is
beginning to make progress.

Ralph

On Mon, May 28, 2012 at 10:43 AM, Szabolcs Horv=E1t <szho...@gmail.com> 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

> --
> Szabolcs Horv=E1t
> Visit Mathematica.SE: http://mathematica.stackexchange.com/

[Szabolcs Horvát]

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:

--
Szabolcs Horvát
Visit Mathematica.SE: http://mathematica.stackexchange.com/

[Szabolcs Horvát]

My preferred method is using the same (undocumented) technique that the
debugger uses. You'll find this technique as well as two others
described here:

http://mathematica.stackexchange.com/questions/1512/how-to-abort-on-any-message-generated

[Christoph Lhotka]

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át wrote:
> Hi Christoph,
>
> Mathematica is used interactive most of the time. It's very different
> from most other programming languages in this respect. 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. In Mathematica we typically don't write
> stand-alone programs. The system is usually used interactive, and the
> most "packaged up" things are functions meant to be used by end-users.
> 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). 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. 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&& 22.2 == -74 k + 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. Version 5's General::spell messages are yet
> another example.
>
> There's no "writing" and "debugging" step here. This is the usual way
> to use the system. Solve and FindMinimum are high level functions
> which are probably more commonly typed than used as parts of other
> functions. 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.
> 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<christop...@fundp.ac.be> wrote:
>> Hi,
>>
>> 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át 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:

[Christoph Lhotka]

[Szabolcs Horvát]

Hi Christoph,

Mathematica is used interactive most of the time. It's very different
from most other programming languages in this respect. 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. In Mathematica we typically don't write
stand-alone programs. The system is usually used interactive, and the
most "packaged up" things are functions meant to be used by end-users.
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). 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. 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 && 22.2 == -74 k + 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. Version 5's General::spell messages are yet
another example.

There's no "writing" and "debugging" step here. This is the usual way
to use the system. Solve and FindMinimum are high level functions
which are probably more commonly typed than used as parts of other
functions. 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.
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 <christop...@fundp.ac.be> wrote:
> Hi,
>

> =C2 in my opinion messages in Mathematica are generated during the evaluation

[Szabolcs Horvát]

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 <christop...@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 == -74 k+ 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<christop...@fundp.ac.be>

[Leonid Shifrin]

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

> >> The input Solve[-26.81 == 194 k + k*l*32.9&& =C2 22.2 == -74k+ k*l*

[Ralph Dratman]

Re: the recent "stop on message" discussion. The earlier-posted
solution from StackExchange suggests adding the following to the top
of a notebook:
- - - - - - - - - -
messageHandler = If[Last[#], Abort[]] &
Internal`AddHandler["Message", messageHandler]
(* The above will abort the computation whenever a message would be printed=
. *)
(* It can be turned off using*)
(* Internal`RemoveHandler["Message", messageHandler] *)
- - - - - - - - - -
This helps, and seems to prevent a complete freeze, but it does not
always terminate the evaluation immediately. The Abort call seems to
wait for something to finish before stopping everything.

>From prior experience, I knew that Interrupt works more quickly than
Abort. I realize this seems a little bit illogical, but nevertheless,
that is my observation: Interrupt gets you out of trouble instantly,
while Abort often doesn't.

I substituted Interrupt in the handler, with much better results, as follow=
s:
- - - - - - - - - -
(* ----- proposed new version ----- *)
messageHandler = If[Last[#], Interrupt[]] &
Internal`AddHandler["Message", messageHandler]
(* The above will immediately (!) put up an Abort dialog offering to *)
(* end the evaluation whenever an enabled message is issued. *)
(* It can be turned off using *)
(* Internal`RemoveHandler["Message", messageHandler] *)
- - - - - - - - - -
This tiny enhancement to Mathematica has proved amazingly helpful, and
I hope everyone will try it. It is a relief not to be always
anticipating the next messy crash.

Let me know if you have any additions or corrections.

Ralph Dratman


On Tue, May 29, 2012 at 5:47 AM, Szabolcs Horv=E1t <szho...@gmail.com> wro=
te:

> 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-m=
essage-generated

[Christoph Lhotka]

Dear all,

I would like to share with you a simple way of debugging your
code in the development phase of your project using standard
Mathematica code instead of modifying internal functions of
the system (which may also imply unpredictable behaviour):

$Pre = If[Length[$MessageList] > 0, Interrupt[], #] &;

The code will open the "Interrupt Evaluation" dialog whenever
a message is generated during evaluation. You decide to abort,
enter a sub-session (to debug) or to continue to the next
step of the evaluation chain.

(If you want to prevent Mathematica to send the messages to
the standard output channel you redirect it to a file or another
notebook/channel using $Messages. See ?$Messages)

************

A simple example: let me assume that I wrote /0 instead of ==0 in the
following expression:

sol = Solve[2 x - 3 y/0, y];
Plot[y /. sol, {x, 0, 1}]

Without setting $Pre (Clear[$Pre] before) you will get 3 error messages
and an empty plot.

Using the assignment for $Pre I can enter a sub-session, correct the
variable sol just by typing

sol=Solve[2 x - 3 y==0, y]
{{y->(2 x)/3}}

return to the main loop using

Return[]

and get the right plot.

Copy & paste the right expression to the original input, clear
$Pre - no message produced - problem solved.

Personally, I would avoid to modify internal stuff of Mathematica.

Best,

Christoph