Run / Break on / Library Errors does not seem to work

[Wolfgang]

Hello,

I have some lines of code where I calculate cosh ( x ); the result may be infinite and thus cause an ERANGE library break; for my case, infinite results are o.k. (actually I am calculating 1 / cosh ( x )) and thus I'd like to avoid those breaks, in particular as those calculations are performed many times in a loop.

Also, there are many occurrences of such functions and I don't want to embed each line with a cosh in a SetBreakOnLibraryErrors ( FALSE ) / SetBreakOnLibraryErrors ( TRUE ) pair (this solves the problem, of course).

I also don't want to disable run time checking in general, I just don't want to have the program interrupted on ERANGE warnings.

As I understood the help (cited below), it should be possible to achieve the same effect by removing the checkmark in the Run / Break on / Library Errors menu:

the way I did it did not have an effect, though... removing the checkmark or setting the checkmark results in ERANGE breaks...

Thanks...

---

When you enable debugging and a National Instruments library function reports an error, LabWindows/CVI can display a run-time error dialog box and suspend execution. You can use SetBreakOnLibraryErrors to enable or disable this feature.

In general, use the Run»Break on»Library Errors command in the Workspace window to enable or disable this feature.

[RobertoBozzolo]

Well, it may be silly, but... The phrase you reported recitates "... a National Instruments library function reports an error...": I have the suspicion that the ANSI C library which exposes cos () function does not pertains to this group 

[Wolfgang]

Well spotted, Roberto!

I still hope that this sophisticated distinction was not intended by the authors...

[D_Biel]

The Break On >> Library Errors menu item does prevent the ERANGE error. In fact it should do the same thing as the SetBreakOnLibraryErrors that you call programatically. However, the SetBreakOnLibraryErrors will supersede the menu item. So if in your code you call SetBreakOnLibraryError(1), then you will break on library errors despite the menu item's setting.

The only option to avoid this only for the cosh function is to wrap it in the SetBreakOnLibraryErrors functions. You could create a new cosh function that includes this and use a #define to turn the setting off and on (if you ever needed to; like if you want to disable break on library errors for the whole program since the function overrides the menu item).

#include <utility.h>
#include <ansi_c.h>

#define HIDE_ERANGE

double _cosh(double a);

int main (int argc, char *argv[])
{
	double val = _cosh(1000);
	
	return 0;
}

double _cosh(double a)
{
	double result;
#ifdef HIDE_ERANGE
	SetBreakOnLibraryErrors(0);
#endif
	result = cosh(a);
#ifdef HIDE_ERANGE  
	SetBreakOnLibraryErrors(1);
#endif
	return result;
}
	

[Wolfgang]

---

@D Biel wrote:

The Break On >> Library Errors menu item does prevent the ERANGE error. In fact it should do the same thing as the SetBreakOnLibraryErrors that you call programatically.

---

Hi Darren,

thanks, this is good news!

---

@D Biel wrote:
However, the SetBreakOnLibraryErrors will supersede the menu item. So if in your code you call SetBreakOnLibraryError(1), then you will break on library errors despite the menu item's setting.

---

This is not so good news as it limits (at least in this case) the menu command!

In my code I have a few calls to SetBreakOnLibraryErrors (that are executed rarely and are not time critical). As a consequence, if a subroutine using the SetBreakOnLibraryErrors (FALSE) - critical function - SetBreakOnLibraryErrors (TRUE) sequence is called before cosh(), the menu command is without effect on cosh() errors. If the cosh() is called first, it should have an effect (I didn't try this case yet).

This seems a bit confusing, to say the least...

It is even more confusing if reading the help sentence:

SetBreakOnLibraryErrors does not affect the state of the Run»Break on»Library Errors option in the Workspace window.

Agreed, it does not change the check mark (if this is what you would call 'the state'), but it does affect the function, and what is 'not so nice', it does this secretly...

You are already used to my comments, so here is another one: I don't like this behavior...  

I will think about your suggested way out, thanks for providing it!

Wolfgang