[Implemented] More sophisticated error trapping

BackupUser · Post by **BackupUser** » Sat Mar 29, 2003 9:13 am

Restored from previous forum. Originally posted by Amiga5k.

I put in my vote for any of the following:
'Try/Catch' (Java, Powerbasic 7)
'On error goto' (Powerbasic and V****l Basic, I think). Any kind of exception handling, really, to catch those really nasty crashes before they take down the whole program.

(Implemented with 'OnError' library)

Russell

***Commodore 64 - Over one million cycles per second, 16 vibrant colors, 3 incredible audio channels and 38,911 Basic Bytes Free! Who could ask for anything more?***

BackupUser · Post by **BackupUser** » Sat Mar 29, 2003 1:41 pm

Restored from previous forum. Originally posted by Kale.

i like the way Python deals with exceptions

Code: Select all

try
    try some code here...
except
    if error then do this...
endtry

or less generic:

Code: Select all

try
    try some code here...
except PB_IOError  ;[i]In love with PureBasic![/i] :)

BackupUser · Post by **BackupUser** » Sat Mar 29, 2003 6:25 pm

Restored from previous forum. Originally posted by ricardo.

Yesterday i was just dreaming to have this in PB, because sometimes its very usefull to catch & handle errors before a crash.

The Python syntaxis is much clear to use.

Best Regards

Ricardo

Dont cry for me Argentina...

BackupUser · Post by **BackupUser** » Sat Mar 29, 2003 6:44 pm

Restored from previous forum. Originally posted by tinman.

Originally posted by ricardo

its very usefull to catch & handle errors before a crash.

Do none of you guys do any error handling then?

I also hope crashing wouldn't always be the result of errors in your programs.

--
I used to be a nihilist but I don't believe in that any more.
(Win98first ed. + all updates, PB3.62, external editor)

BackupUser · Post by **BackupUser** » Sat Mar 29, 2003 7:48 pm

Restored from previous forum. Originally posted by Amiga5k.

Of course we do, silly!

But sometimes there's that chance that some user is going to do something that you never even dreamed of and crash the whole program/system. If it's a critical application, then error trapping is especially necessary. Yes, it slows code a bit, but it's a good trade off in these situations. There must be SOME reason that almost all modern languages have error trapping in some form or another (Java, Python, Powerbasic, Vi**** basic, etc).

Russell

***Commodore 64 - Over one million cycles per second, 16 vibrant colors, 3 incredible audio channels and 38,911 Basic Bytes Free! Who could ask for anything more?***

BackupUser · Post by **BackupUser** » Sat Mar 29, 2003 8:13 pm

Restored from previous forum. Originally posted by ricardo.

I also hope crashing wouldn't always be the result of errors in your programs.

Dont worry about.

However most languages offers an easy way to chatch and manage errors and exceptions. This is specially usefull from impredictible things.
Once i have a crash of my software because my app was trying to read some string but the user has chineese windows and something strange happends but it crashes.
I still dont understand what fails but as i dont have any chineese windows around its difficult to get the error.
The string that i read its suppoused to have some chr(141), i dont know why but this causes the crash, when i change those chararacter in the code to chr(165) or something like that the software runs perfect.?!?!?!?!
Its was developed on VB and not PB.

In fact i found some example posting this answer... i tried to put the chr(141) on screen, i press ALT and type 0141 and the forums jumps to another page!!
I dont know if it was teh Forum, Opera or XP or something, but someone never imagine that i would do that

and do not catch the error

Best Regards

Ricardo

Dont cry for me Argentina...

BackupUser · Post by **BackupUser** » Sat Mar 29, 2003 9:21 pm

Restored from previous forum. Originally posted by tinman.

Originally posted by Amiga5k

Of course we do, silly! But sometimes there's that chance that some user is going to do something that you never even dreamed of and crash the whole program/system.

I disagree. I fail to see how the user can do something you've never dreamed of. Ricardo's example falls into this category - if the user can enter text then it is logical to think they they can enter any ASCII (or UniCode) character. If it is a problem with the system then is it our job to patch/hack/workaround/fix the system? If the problem was caused by the Chr(141) then that is because ricardo either couldn't or didn't specifically test that situation. But it should have been logical to think it might be entered.

So while it might be useful to use it as a default / fallback error handler, saying that users can break your program with stuff you never dreamed of implies a lack of consideration about what your program is doing. Or something is broken at a lower level than your code.

If it's a critical application, then error trapping is especially necessary. Yes, it slows code a bit, but it's a good trade off in

Error trapping should not be any slower than normal error checking. Effectively you have the same thing only instead of you writing the error handling, the system function has it built it. When it detects an error, it sets a flag/variable describing the error and exits whatever it's doing and either your application checks the error variable or it automatically jumps to your handler. The only time it would be slower is in the case that it has to handle the error.

these situations. There must be SOME reason that almost all modern languages have error trapping in some form or another (Java, Python, Powerbasic, Vi**** basic, etc).

Some reasons could include:
it's the latest cool idea, so you have to have it to look cool
the authors of the language know that their users will be lazy
the authors of the system/function calls are too lazy to provide any feedback through return codes

I don't think PB shouldn't have trapping of this kind, but it really winds me up when programmers use it badly or use it as the only means for doing all their error checking.

--
I used to be a nihilist but I don't believe in that any more.
(Win98first ed. + all updates, PB3.62, external editor)

BackupUser · Post by **BackupUser** » Sat Mar 29, 2003 9:29 pm

Restored from previous forum. Originally posted by ricardo.

My chineese trouble was more strange... the user dont type the chr(141), my app read this string and search for the chr(141). Ok, it works on more than 180,000 downloads but fails in ONE pc, in fact i has another 3 or 4 chineese customers and never receive any complaints about crashing.
My user told me that she thinks that it was caused because her window has chineese font but mixed in some way (i dont understan all her explanation) with english stuff or something like that.

But, YES, errors are always HUMAN eerors since software is only developed by humans, BUT Â¿why did we use computers and not the hands to count? Because computers make life easier... then some errors are very difficult to preview and i want PB to make my life easier

Best Regards

Ricardo

Dont cry for me Argentina...

BackupUser · Post by **BackupUser** » Sun Mar 30, 2003 6:29 pm

Restored from previous forum. Originally posted by plouf.

And what will happen if error Trapping has an error in it ?
should check infinitive cases before execute a command ?
or should all problems redirected to other ?

btw if i am not wrong Chinese/Japanese use a kind of fot
engine for ASCII fonts i.e. two char's are proccessed to make a single
maybe this is the prob ?

Christos

BackupUser · Post by **BackupUser** » Sun Mar 30, 2003 8:29 pm

Restored from previous forum. Originally posted by ricardo.

Ricardo's example falls into this category - if the user can enter text then it is logical to think they they can enter any ASCII (or UniCode) character. If it is a problem with the system then is it our job to patch/hack/workaround/fix the system? If the problem was caused by the Chr(141) then that is because ricardo either couldn't or didn't specifically test that situation. But it should have been logical to think it might be entered.

No, is THIS forums what dosent accept chr(141) using XP & Opera 7.02
Please read more carefully.

In my problem i need to read some data and find where is the chr(141), on every windows (Except chineese and maybe japaneese, korean, etc) it dosent present ny problem, well... in chinesee windows it crashes the application.
Now i read Christos explanation and maybe there was the error, i dont know, but of course i never imagine that.

Did you ever check your software under Chineese windows????

I give you an example... Winamp dosent works well neither with Chineese windows (the same user told me that when i was trying to figure out which was the error) because the way that we have to read and understand paths are different from Chineese ones, i think that i understand that they used characters that our typical requesters dont accept as a valid character or something like that.

but it really winds me up when programmers use it badly or use it as the only means for doing all their error checking.

Just relax and be so nice to give us a little of patience

Best Regards

Ricardo

Dont cry for me Argentina...

BackupUser · Post by **BackupUser** » Sun Mar 30, 2003 8:51 pm

Restored from previous forum. Originally posted by GPI.

I don't read the complete thread, but look at this

(i found this in the german-forum, from purefan)

IMPORTANT: Deactivate the Debugger!

Code: Select all

Global CrLf.s 
CrLf=Chr(13)+Chr(10) 

;'------------------------------------------------------------------------ 
;             error-ROUTINE 
;'------------------------------------------------------------------------ 


;Two global Variables for the deugger
Global DebuggerVal.l 
Global DebuggerEIP.l 


;this procedure will called, when a error happend
;and this procedure need a POINTER to the Error-discription
Procedure MyDebugger(*lpEP.EXCEPTION_POINTERS) 
 *cont.CONTEXT = *lpEP\ContextRecord        ;Lese die 1. Beschreibung in eine Struktur 
 *rec.EXCEPTION_RECORD = *lpEP\pExceptionRecord  ;Lese die 2. Beschreibung in eine Struktur 

 If DebuggerVal=0                 ;The user don't klick on ignore?

  DisplayDebuggerMessage: 

  ;Show a Dialog with the Registers.

  Title.s = "MyDebugger" 
 
  Message.s = "Program crashed!" + CrLf 
  Message.s + "" + CrLf 
  Message.s + "Register-values:" + CrLf 
  Message.s + "EDI="+Str(*cont\edi) + CrLf 
  Message.s + "ESI="+Str(*cont\esi) + CrLf 
  Message.s + "EBX="+Str(*cont\ebx) + CrLf 
  Message.s + "EDX="+Str(*cont\edx) + CrLf 
  Message.s + "ECX="+Str(*cont\ecx) + CrLf 
  Message.s + "EAX="+Str(*cont\eax) + CrLf 
  Message.s + "EBP="+Str(*cont\ebp) + CrLf 
  Message.s + "EIP="+Str(*cont\eip) + CrLf 
  Message.s + "ESP="+Str(*cont\esp) + CrLf 
  Message.s + "" + CrLf 
  Message.s + "Click on ignore to ignore it and do the next command in the programm," + CrLf 
  Message.s + "Retry to try it again," + CrLf 
  Message.s + "or Abort to exit the programm" 

  Flags.l = 2 | 16          ;AbortRetryIgnore | Critical 

  SelButton.l = MessageRequester(Title,Message,Flags) 

  ;check the answer

  If SelButton=3           ;Abort 
   ProcedureReturn 1    ;...close Programm without a errormessage
   
 
  ElseIf SelButton=4         ;Retry 
   ProcedureReturn -1   ;..the same command
  
  ElseIf SelButton=5         ;Ignore 
   *cont\eip+1        ; set the pointer to the next command
   DebuggerVal=1       ;if the error now happend, the command was longer than one byte
   DebuggerEIP=*cont\eip 
   ProcedureReturn -1   ;retry the command
 
  EndIf 
  
 Else             ;the user pressed ignore on the error-message before
 
  If DebuggerEIP*cont\eip    ;a new error?
   Goto DisplayDebuggerMessage  ;yes-> new dialog
  EndIf 
 
  *cont\eip+1           ;next byte
  DebuggerEIP=*cont\eip 
  ProcedureReturn -1      ;retry
  
 EndIf 

EndProcedure 

Procedure InitDebugger() 
 SetUnhandledExceptionFilter_(@MyDebugger())  ;Debugger aktivieren 
EndProcedure 

Procedure UnloadDebugger() 
 SetUnhandledExceptionFilter_(0)        ;Debugger deaktivieren 
EndProcedure 


;'------------------------------------------------------------------------ 
;              BEISPIEL 
;'------------------------------------------------------------------------ 

InitDebugger() 

MessageRequester("","In der folgenden Zeile wird eine Division durch 0 ausgefÃ¼hrt!",0) 

Y=0 
X=999/Y 

MessageRequester("","Diese Zeile wird ausgefÃ¼hrt, obwohl ein Fehler aufgetreten war!",0) 

UnloadDebugger()

PII 333, 256MB, Asus TNT2Ultra 32MB, AWE Gold 64 4MB

BackupUser · Post by **BackupUser** » Sun Mar 30, 2003 9:02 pm

Restored from previous forum. Originally posted by tinman.

Originally posted by ricardo

No, is THIS forums what dosent accept chr(141) using XP & Opera 7.02
Please read more carefully.

You mean this section from your post:

Once i have a crash of my software because my app was trying to read some string but the user has chineese windows and something strange happends but it crashes.
I still dont understand what fails but as i dont have any chineese windows around its difficult to get the error.
The string that i read its suppoused to have some chr(141), i dont know why but this causes the crash, when i change those chararacter in the code to chr(165) or something like that the software runs perfect.?!?!?!?!

So, your software has some problem with Chr(141), which is what I mentioned. I never made any reference to anything accepting Chr(141) or not, just there was some problem with it. Or maybe you refer to your other posting after my one which explains the situation a bit more? Hmm, terribly sorry for not rushing back and editing my post.

Did you ever check your software under Chineese windows????

No. But then I'm not going to try to use that as an excuse to get features implemented in PureBasic.

but it really winds me up when programmers use it badly or use it as the only means for doing all their error checking.
Just relax and be so nice to give us a little of patience

I'd much rather post a message questioning why someone would like some feature. You never know, it may provoke some discussion about why it would be a good idea or not. Would it be better that all ideas and suggestions be added to PureBasic without any input from any of the other users (I'm thinking of the infamous "return without gosub" checks which were added on the suggestion of one person).

--
I used to be a nihilist but I don't believe in that any more.
(Win98first ed. + all updates, PB3.62, external editor)

BackupUser · Post by **BackupUser** » Sun Mar 30, 2003 9:31 pm

Restored from previous forum. Originally posted by PB.

> I fail to see how the user can do something you've never dreamed of.

Here's an example: I had an app where one single user reported to me that it didn't work.
Everyone else said it was fine. Neither of us could work out what was wrong. My app was
to simply move the Calculator to the centre of the screen. That simple. It wouldn't do
it for him. My app simply looked for a window titled "Calculator" (using FindWindow) and
moved it to the centre. His OS was English-language and when he sent me a screenshot
I could see that his window title had "Calculator" on it as expected, and yes, it was the
standard Windows calculator (not a third-party version with that title). So why wouldn't
it work? It was due to something I didn't think of. Can you work it out?

BackupUser · Post by **BackupUser** » Sun Mar 30, 2003 10:01 pm

Restored from previous forum. Originally posted by Amiga5k.

Wow Tinman, you must be the brainiac of the computer programming world if you think you can predict EVERY possible thing the user is going to try (intentionally or otherwise):

Ricardo's example falls into this category - if the user can enter text then it is logical to think they they can enter any ASCII (or UniCode) character. If it is a problem with the system then is it our job to patch/hack/workaround/fix the system? If the problem was caused by the Chr(141) then that is because ricardo either couldn't or didn't specifically test that situation. But it should have been logical to think it might be entered.

So Ricardo's supposed to test his program on every version of Windows in the world (There are dozens, BTW) for every eventuality? . Do you think you can produce a program of any appreciable length that can't be crashed? You'd be the first ever, my friend! In Ricardo's case, an exception handler would have 'caught' the potential crash and allowed his program to report the error to the user, save information first, etc.

As far as slowing the program down, depending on how the exception handling is done, sometimes extra code is inserted in the executable loop which will slow down the program. Ever notice that PB runs slower in Debug mode? But this slow down is worth it if you're working with critical apps. I think you're confusing error checking with exception handling. They're not the same thing. Error checking is something we should all be doing (i.e. Check to see if a file exists before you try to load it, etc). Exception handling is the next step up from that.

Russell

***Commodore 64 - Over one million cycles per second, 16 vibrant colors, 3 incredible audio channels and 38,911 Basic Bytes Free! Who could ask for anything more?***

BackupUser · Post by **BackupUser** » Sun Mar 30, 2003 10:10 pm

Restored from previous forum. Originally posted by tinman.

Originally posted by PB

So why wouldn't it work? It was due to something I didn't think of. Can you work it out?

Well I'd guess at they either:

- Used some kind of theming or window tart-up program which modified the window titles to something equally pointless like ".oO Calculator Oo."
- Hex edited the calculator program to use a different string, but still with the word "calculator" in it
- Renamed the filename. Perhaps calculator takes its window name from it's file
- Were running another program which had a window title "calculator" and your program found that one rather than the intended one
- I've only got Windows 98 here, so I don't know whether you can assume that there is such a thing as a "standard" calculator. Or whether every single version of the calculator shipped with Windows has the same title string.

I suppose I should have qualified my never dreamed of statement with "can do something inside your application", which is what I was thinking of at the time. I had not considered system factors or interaction with other programs. I guess I should have also said "or do something you never thought of and couldn't handle".

But let me ask you: did your program fall over? Sure it may not have move the calculator to the centre of the screen, therefore failing in its intended task. But I'm sure you were able to handle the error of not finding the window. Alright, if you really never thought of it fine, but you were still able to handle it without the magical cure all of error trapping?

--
I used to be a nihilist but I don't believe in that any more.
(Win98first ed. + all updates, PB3.62, external editor)