 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : ON ERROR SKIP and Interrupts
Page 1 of 3   |
|||||
| Author | Message | ||||
vegipete Guru  Joined: 29/01/2013 Location: CanadaPosts: 1132 |
Well, this seems like an interesting anomaly. settick 25,TestMe,1 do on error skip a = 2 / 0 loop sub TestMe i = i + 1 end sub Turn off the timer interrupt and it works fine. (I'm testing on a CMM2.) It's pretty clear why it fails, but how should it behave? Visit Vegipete's *Mite Library for cool programs. |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1114 |
@Vegipete Other way around I think mate  , with settick enabled, I get the divide by zero message, with settick disabled, it just goes into nowhere land.I think this would be expected as the on error skip is jumping over the loop command into ??? I think the settick interrupt sub is effectively the next instruction after the loop statement and this is where the error condition jumps in? If you put a line in after the a = 2/0 like print "hi" or whatever, that will be evaluated after the error line is skipped over and the loop will then also be evaluated whether settick is enabled or not. Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1132 |
Exactly. The ON ERROR SKIP statement should prevent the divide by zero from ever reporting an error. However, because of the interrupt, sometimes (often?) the divide by zero line is NOT the next statement after the ON ERROR. Print i at the prompt after the error - the value can vary depending on how many times the ISR fired before the error happens. The issue is, because of interrupts, you can't determine which statement/s might be skipped by the ON ERROR SKIP command. Visit Vegipete's *Mite Library for cool programs. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
Oh horrors. That really reduces the value of ON ERROR SKIP! Could it be a change somehow introduced accidentally? Is there a workaround (other than turning off interrupts)? I suppose MMBasic could be changed not to look for interrupts until after the next statement... John Edited 2022-04-09 18:30 by JohnS |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Perhaps the setting of ON ERROR needs to be ignored within interrupts, or taking it a step further there should be separate ON ERROR states for the normal path and the interrupt path. Fun!!! Best wishes, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
What's up with turning off interrupts during an ON ERROR SKIP? They won't be off long. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
I'm probably in a minority of one on this but personally I would remove ON ERROR from the language entirely. I've never used it in "real" code and never would. IMHO is is just a mechanism for hiding programming that doesn't properly cater for the various conditions that may arise. I'm pretty sure all variants of MMbasic will display the symptoms found by vegipete and I certainly won't be making changes to the firmware to get round them. |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Please don't do that, it's vital to allow unit-testing of error conditions. I think there are File I/O error conditions for which MMBasic doesn't provide commands/functions to detect before they report an error. Best wishes, Tom Edited 2022-04-09 20:34 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Deleted duplicate post. Edited 2022-04-09 19:43 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1132 |
This came about because I was blitting something onto the screen, except that sometimes the image wasn't visible. Instead of testing for visibility, I used an ON ERROR to skip off screen drawing. Simple enough. Most other drawing commands happily do nothing if acting off-screen, but not BLIT. This lazy (Matherp NOT-approved ;) method started to fail once I added interrupts. ===================== If there _were_ to be a solution, JohnS and Mixtel90's idea seems most logical: after an ON ERROR SKIP [n] statement, interrupts would not be serviced for 1 (or n) interrupts. I'm not aware of a method of stopping (and restarting) all possible interrupts in MMBasic. This change to ON ERROR behavior would add a potentially useful ability to stop interrupts while a set of instructions that must be atomic executes. Edited 2022-04-10 01:41 by vegipete Visit Vegipete's *Mite Library for cool programs. |
||||
| toml_12953 Guru Joined: 13/02/2015 Location: United StatesPosts: 442 |
It can hide sloppy code but it can also recover from user and hardware errors. Suppose you ask for a filename to open and the user types in a filename that doesn't exist? Do you really want the program to exit with an error message or do you want to give the user another chance to enter the filename correctly? How about a hardware error while reading or writing a file? No commercial program should ever exit unexpectedly. There should be no way out of the program other than the graceful exit designed by the programmer. I worked in IT for over 40 years and I'd have been fired if my users ever had the program dump them to a DOS or bash prompt. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
Agreed, it has its place. :) When messing with hardware though, you should always *expect* a failure and be pleasantly surprised if it works ok (unless the programme is something pretty trivial). If that means disabling interrupts while you activate a drive or something then so be it. There could be anything happening - cat asleep on a drive causing it to overheat, data fallen off the floppy (along with the magic rust powder), user's little daughter "posted" things into the drive slot (don't you dare laugh!) - anything. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1593 |
+1 causality ≠correlation ≠coincidence |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
"File FUBAR - Jam on Disk" :( Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
Example of something that can't be coded round? |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
I really don't want to play this game since we both know you aren't actually going to remove ON ERROR SKIP, but at a guess, missing SD card, full SD card, unreadable SD card, unwritable SD card ? Best wishes, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Plus on performance grounds isn't an ON ERROR SKIP much cheaper than what at a minimum would be an IF statement and a variable lookup? I'm really surprised this hasn't come up before (maybe it has?), I guess you just have to be really unlucky for an interrupt to fire between an ON ERROR SKIP and a statement that can and in a given instance does throw an error. Best wishes, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1642 |
I use it to test whether a file exists or not in Geoff's MMBasic for Windows. function file_exist(fe$, fn) on error skip 1 open fe$ for input as #fn if mm.errno = 0 then close #fn file_exist = mm.errno = 0 end function Is there a better way? Bill Keep safe. Live long and prosper. |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
Different, not "better" file$ = "testing.bas" IF MM.INFO$(SDCARD) = "Ready" THEN OPEN "testit.txt" FOR OUTPUT AS #1 CLOSE #1 PRINT MM.INFO$(FILESIZE file$) ' existing file PRINT MM.INFO$(FILESIZE "test") 'existing directory PRINT MM.INFO$(FILESIZE "wrong.nam") 'nonexisting file 'junk$ = dir$("",file) 'without this, zero bytes on pico files give error PRINT MM.INFO$(FILESIZE "testit.txt") ELSE PRINT "Put it back!!!" ENDIF On the pico, I get an error for zero byte files unless you do a DIR$() first. !!A BUG!! On MMB4W, there is no SD card so that line gives an error as expected. Filesize returns filesize (including zero) if present, -2 if directory or -1 if not found. Edit: Sorry Bill, I just noticed that you are using the original MMBasic.exe, not MMB4W so most of my commands are missing. Jim Edited 2022-04-10 13:12 by TassyJim VK7JH MMedit |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
i am inclined to side with Peter on this one, even though i did use ON ERROR in a piece of test code i'd run over every E-28 module built. i also believe i may have been one of the people who pushed for Geoff to include some sort of error catching  bearing in mind that i am mostly just interested in the MX170 version of mmbasic, used in embedded applications, in general when an error occurs things should stop and tell the operator (or trigger a watchdog event). i would suggest that ON ERROR should be classed alongside TRACE ON|OFF and MEMORY. that is, things used during development but not left in the final production code. one simple solution: edit the mmbasic manuals to clearly state that ON ERROR may cause unexpected behavior when an interrupt is triggered. with any product, there will always be some 'odd' behaviors that exist, the important thing is that these behaviors are clearly documented  just my opinion, rob :-) Edited 2022-04-10 14:27 by robert.rozee |
||||
| Page 1 of 3 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
