Errors in Clearwin and crashes

For discussion here I already suggested kind of unusual in Fortran 'crash and burn' world idea not to allow any crashes in Clearwin at all. At least for me time and kicks in my butt tell that this was very reasonable idea. Lost one day again because GUI crash. Crash of GUI may kill one day or one week of run. No matter what is the problem the Clearwin has to allow the main simulation to complete the run. Fixing bugs can be done later.

At the end it is just the GUI, this is not a crash from, say, negative number under square root, and so it would be just fine to have the warning window at run time saying that %il for example has zero value. Who cares, that means that %il still allow the %dd to have at least single value. Crash took place with this construct ('Negative or zero range implied with %il format')

ii=winio('%dd%il%6rd%`il)',1,1,max(1,n_ExpCases), iVariable) 

when by mistake happen n_ExpCases=0 and so %il restricted %dd just for iVariable=1 which is perfectly OK.

As a discussion, may be in cases like this instead of crash Clearwin has to ask user

1. Would you like to cancel run?
2. Take this %il zero or negative range and continue run
3. Completely remove influence of %il and continue run

There will be some contexts where a 'continue' will be possible both logically and within the current design of ClearWin+ but for the most part recovery is either not possible (logically) or the current design does not allow for continuation without recoding vast amounts of the ClearWin+ library.

I understand this is not easy task, may be even not doable. But please think if it can be partially implemented. For example with the %il case above when the range is zero (very often error) - it should work without crash. As to negative %il I do not know, may be still the deactivation of %il is better option then crash.

A number of years ago I suggested that a zero range ought to be admissable for %il and %fl, but then it should make the control write only. It does not seem unreasonable to me that such a compromise should exist.

At version 7.1, Paul (re-?) discovered set_integer_limits@ and set_float_limits@ and for some reason I thought that he'd addressed the issue of the limits being the same, but on searching through cwplus.enh I couldn't find it, and so must have been mistaken. Those set limits routines must also check for admissable limits, and the problem of going from zero range to a non-zero range which would imply going from write-only to read/write might be more intractable.

Incidentally, neither the format code reference nor the section on interactive i/o in FTN95.CHM say that a negative or zero range gives rise to an error condition. A negative range is in some ways a more 'obvious' error than a zero range.

Dan's nExpCases example is one where (sorry Dan) there is an overall programming error in ever letting nExpCases be zero, as it was programmer's responsibility to check for that. The issue where I think that Clearwin+ is wrong is when nExpCases is 1, but of course, Dan could have programmed an alternative write-only WINIO@ statement for that case.

Presumably, nExpCases is input somewhere else in the program, and that is the point where it needed to be checked.

The structural engineers' equivalents include: 'This structure has no loads, so it will not deform' 'This structure has no members to carry any loads' 'This structure has no foundations, and so will fly'

One quickly learns to check input for such cases or their analogues in one's own field. The third case message is more comprehensible than a failed attempt to divide by zero in a matrix inversion routine, which is what happens if you plough on regardless.

Eddie

Oh, and some further thoughts on what constitutes a crash. From the perspective of FTN95 it isn't a crash if FTN95 detects an error case and terminates with an error message, doesn't leave any orphaned windows, and leaves Windows operating normally.

From the perspective of an end user of the software, this is a major crash about which they can do nothing. An end-user won't know or care if it is a Windows problem, a .NET problem (if relevant), a Fortran problem or a Clearwin problem, and many developers won't be able to distinguish between them either!

Eddie

Eddie Good that you support allowing zero range for %il. Otherwise we have to write if-then-else construct to avoid this %il when the range is zero.

As to not allowing crashes caused by the Clearwin GUI here is another example of crash I got today: 'Invalid initial value for %rf format. Are you sure the variable is initialized?'. Crash will cause me to lose a lot of time to reconstruct the same conditions and even start the code again takes now a lot of time so i'd take chance to run defective GUI anyway (if Clearwin allowed me to continue ignoring this damn %rf which I do not know what the heck is doing), in the hope that may be what I will get from the rest of broken GUI will be usable to me. I will fix this %rf later. I am even willing to generate totally crazy GUI of orphaned windows to allow the code to run. Even rebooting Windows is often takes much less time. Windows is smart to take care if something like that is out of control. Ones some error generated me like 10000 open windows (they were falling like an avalanche) but then all stopped and I closed them with one click

Typically GUI does not destroys anything in the main running code when you open it during its run. In my case I often use it to look at something in detail or change something. This specific %rf for example could be one of 10000 controls of the pretty complex GUI and has no value to me at all, it might be also not used in this specific task which is running (hence probably why it was not initialized). The result is terrible - that this tiny piece of worthless dust causes crash and abort of the entire code

I have now added an option to continue when %IL or %FL are invalid. This is a particularly simple error context so it has only taken about an hour to work out the implications and apply the change. The %rf error is more complex (what can ClearWin+ do to recover? - a rhetorical question). Then there are hundreds of similar error reports.

Eddie is right. set_integer_limits@ and set_float_limits@ can be used. See the ClearWin+ enhancements file, item 365.

Thanks for the fixes and hints. In more complex cases then my current one these enhancements will be definitely needed. I was thinking by the way in the same key - how to react on dynamically changing environment where fixed %il and %fl limits can not be used? What if I already opened the GUI with the fixed MIN and MAX limits and meantime the situation changed? These routines solve this problem. Thanks again, this often happened with this compiler that I come to some needs and ooops somehow magically this really tricky stuff (definitely no other compiler is even at this lever of complexity) is already there, I just did not know about it

Paul,

Does that mean that a zero range is no longer an error condition, or is it a case that one can recover from?

Eddie

Eddie

Invalid limits raise an error condition as before but now you get a dialog box and you can opt to continue, in which case the offending %il/%fl code is ignored.

My suggestion would be that the particular case of zero range excluded from being an error. Do you see something fishy here I don't?