Return to Question

A typical situation I run into when notebook grows beyond a couple of functions -- I evaluate an expression, but instead of correct answer I get Beep followed by dozens of useless warnings followed by "further Output of ... will be suppressed"

One thing I found useful -- use Python-like "assert" inside functions to enforce internal consistency. Any other tips?

Assert[expr_, msg_] := If[Not[expr], Print[msg]; Abort[], None] 

edit 11/14 A general cause of a warning avalanche is when a subexpression evaluates to "bad" value. This causes the parent expression to evaluate to a "bad" value and this "badness" propagates all the way to the root. Built-ins evaluated along the way notice the badness and produce warnings. "Bad" could mean an expression with wrong Head, list with wrong number of elements, negative definite matrix instead of positive definite, etc. Generally it's something that doesn't fit in with the semantics of the parent expression.

One way do deal with this is to redefine all your functions to return unevaluated on "bad input." This will take care of most messages produced by built-ins. Built-ins that do structural operations like "Part" will still attempt to evaluate your value and may produce warnings.

I'm wondering if there's a way to leverage type checks built into existing Mathematica functions, perhaps something that interrupts whole evaluation whenever any Message is printed?

A typical situation I run into when notebook grows beyond a couple of functions -- I evaluate an expression, but instead of correct answer I get Beep followed by dozens of useless warnings followed by "further Output of ... will be suppressed"

One thing I found useful -- use Python-like "assert" inside functions to enforce internal consistency. Any other tips?

Assert[expr_, msg_] := If[Not[expr], Print[msg]; Abort[], None] 

edit 11/14 A general cause of a warning avalanche is when a subexpression evaluates to "bad" value. This causes the parent expression to evaluate to a "bad" value and this "badness" propagates all the way to the root. Built-ins evaluated along the way notice the badness and produce warnings. "Bad" could mean an expression with wrong Head, list with wrong number of elements, negative definite matrix instead of positive definite, etc. Generally it's something that doesn't fit in with the semantics of the parent expression.

One way do deal with this is to redefine all your functions to return unevaluated on "bad input." This will take care of most messages produced by built-ins. Built-ins that do structural operations like "Part" will still attempt to evaluate your value and may produce warnings.

Having the debugger set to "break on Messages" prevents an avalanche of errors, although it seems like an overkill to have it turned on all the time

A typical situation I run into when notebook grows beyond a couple of functions -- I evaluate an expression, but instead of correct answer I get Beep followed by dozens of useless warnings followed by "further Output of ... will be suppressed"

One thing I found useful -- use Python-like "assert" inside functions to enforce internal consistency. Any other tips?

Assert[expr_, msg_] := If[Not[expr], Print[msg]; Abort[], None] 

edit 11/14 A general example of a warning avalanche is when a subexpression evaluates to "bad" value. This causes the parent expression to evaluate to a "bad" value and this "badness" propagates all the way to the root, with each level of evaluation producing new warning. "Bad" could mean an expression with wrong Head, list with wrong number of elements, negative definite matrix instead of positive definite, etc. Generally it's something that doesn't fit in with the semantics of the parent expression.

One way do deal with this is to redefine all your functions to return unevaluated on "bad input." This will take care of most messages produced by built-ins. Built-ins that do structural operations like "Part" will still attempt to evaluate your value and may produce warnings.

I'm wondering if there's a way to leverage type checks built into existing Mathematica functions, perhaps something that interrupts whole evaluation whenever any Message is printed?

A typical situation I run into when notebook grows beyond a couple of functions -- I evaluate an expression, but instead of correct answer I get Beep followed by dozens of useless warnings followed by "further Output of ... will be suppressed"

One thing I found useful -- use Python-like "assert" inside functions to enforce internal consistency. Any other tips?

Assert[expr_, msg_] := If[Not[expr], Print[msg]; Abort[], None] 

edit 11/14 A general cause of a warning avalanche is when a subexpression evaluates to "bad" value. This causes the parent expression to evaluate to a "bad" value and this "badness" propagates all the way to the root. Built-ins evaluated along the way notice the badness and produce warnings. "Bad" could mean an expression with wrong Head, list with wrong number of elements, negative definite matrix instead of positive definite, etc. Generally it's something that doesn't fit in with the semantics of the parent expression.

One way do deal with this is to redefine all your functions to return unevaluated on "bad input." This will take care of most messages produced by built-ins. Built-ins that do structural operations like "Part" will still attempt to evaluate your value and may produce warnings.

I'm wondering if there's a way to leverage type checks built into existing Mathematica functions, perhaps something that interrupts whole evaluation whenever any Message is printed?

A typical situation I run into when notebook grows beyond a couple of functions -- I evaluate an expression, but instead of correct answer I get Beep followed by dozens of useless warnings followed by "further Output of ... will be suppressed"

What are some strategies for preventing this kind of situation?

Two things I found useful -- use Python-like "assert" inside functions to enforce internal consistency, and Protect especially important read-only global variables. Any other tips?

Assert[expr_, msg_] := If[Not[expr], Print[msg]; Abort[], None] 

edit 11/13 One example when such "warning avalanche" happens when built-in returns "$Failed" and the computation continues operating on "$Failed" as if it were a real value. Is there a way to force Mathematica to Abort whenever $Failed is produced? Or alternatively, to Interrupt[] whenever any warning is printed?

edit 11/14 A general example of a warning avalanche is when a subexpression evaluates to "bad" value. This causes the parent expression to evaluate to a "bad" value and this "badness" propagates all the way to the root, with each level of evaluation producing new warning. "Bad" could mean an expression with wrong Head, list with wrong number of elements, negative definite matrix instead of positive definite, etc. Generally it's something that doesn't fit in with the semantics of the parent expression.

One way do deal with this is to redefine all your functions to return unevaluated on "bad input." This will take care of most messages produced by built-ins. Built-ins that do structural operations like "Part" will still attempt to evaluate your value and may produce warnings.

A typical situation I run into when notebook grows beyond a couple of functions -- I evaluate an expression, but instead of correct answer I get Beep followed by dozens of useless warnings followed by "further Output of ... will be suppressed"

One thing I found useful -- use Python-like "assert" inside functions to enforce internal consistency. Any other tips?

Assert[expr_, msg_] := If[Not[expr], Print[msg]; Abort[], None] 

edit 11/14 A general example of a warning avalanche is when a subexpression evaluates to "bad" value. This causes the parent expression to evaluate to a "bad" value and this "badness" propagates all the way to the root, with each level of evaluation producing new warning. "Bad" could mean an expression with wrong Head, list with wrong number of elements, negative definite matrix instead of positive definite, etc. Generally it's something that doesn't fit in with the semantics of the parent expression.

One way do deal with this is to redefine all your functions to return unevaluated on "bad input." This will take care of most messages produced by built-ins. Built-ins that do structural operations like "Part" will still attempt to evaluate your value and may produce warnings.

I'm wondering if there's a way to leverage type checks built into existing Mathematica functions, perhaps something that interrupts whole evaluation whenever any Message is printed?