posted March 14, 2005 04:10 AM            

Many errors in your source code can be caught at the time of compilation. A simplistic example might be something like ASC(x&). It's obvious this is an error because this function requires a string parameter, not the numeric variable shown here. This type of error is always caught at compile time. Now, there can always be some discussion about the best way to report these errors, and we've had many discussions of this type here on these forums. In particular, there are always conflicting opinions about whether LOOP mismatches should be displayed at the top or bottom, and the wording that should be used, but the fact is these errors are always caught, as far as we know, and Mr. Salius' examples are just not accurate. If anyone has an example of a "flaw" in this regard, we urge you to report them to PowerBASIC support with an example of the problem.

Other types of errors can only be caught at run-time. PowerBASIC always tests for run-time errors which are beyond your control -- for example, disk errors. If a disk I/O function fails, an error will always be generated. The next level of error checking involves the most common problems, like array bounds errors. These can be trapped by enabling error checking with DEBUG ERROR ON. Once your program is complete and stable, this error checking is usually disabled. Last, we have function bounds errors. For example, CHR$(257). Just like most C compilers, PowerBASIC does not check for this category of error in the interest of performance, because it's an item under control of the programmer. If you aren't sure you're passing a value of 0 to 255 to CHR$(), you can readily write error checking code yourself -- then take it out in your final program.

This is a short description of the philosophy we use for error checks in PowerBASIC programs. We're always eager to hear other opinions and suggestions. If enough folks request a change, we'll give it very serious consideration. We're here to give you the tools you need -- tools which work the way that will help you the most. So don't hesitate to tell us what you think. But please be courteous to everyone here. There is never, ever a reason to be insulting. There is never, ever a reason to use disparaging words.

Thanks for reading this far.

Regards,

Bob Zale
PowerBASIC Inc.

posted March 14, 2005 05:11 PM            

I HEREBY BRING TO YOUR ATTENTION THAT A LAWSUIT WAS FILED AGAINST YOU AND…

Hold on, man! Don’t tremble! Don’t be stiff! I am kidding…

Look, let me put it as a simple question:

WHY DOESN’T PBCC HANDLE ERRORS THE SAME WAY AS VB DOES?

If there are errors (and there are plenty of errors in every serious program, written by any serious programmer), VB will stop immediately. VB will show precisely what error encountered and in what line. I don’t have to worry that I make a mistake that would be very hard to catch. The error is even highlighted. Press F1 and get a bible of help regarding the error. If the error is grave, VB shuts itself down, so that the dreadful swap file won’t feed the program with dangerous data. I do not ask that PBCC do it exactly and completely like VB. Just the precise line, the exact line where the error occurred — that would do. I don’t even ask PBCC to define the error. I can figure out what went wrong IF I am at the exact line.

IS THAT TOO MUCH TO ASK, O INDUBITABLY WISE ONE?

Ion Saliu
Doctor and Patient in Errare Humanum Est
www.saliu.com

posted March 14, 2005 05:20 PM            

I'll make a guess: because PB/CC is not VB?

Seriously, if VB-Style compile-time error handling is indispensable, I think you should be using VB.

(Not an endorsement of PB/CC compile time error handling, which is pretty run-of-the-mill; and the improvements (in 3.0x) only weakened it.)

posted March 14, 2005 05:33 PM            

Regards,

Bob Zale
PowerBASIC Inc.

posted March 14, 2005 06:06 PM            

I’m glad you start asking good questions, o wise one!

“Have you ever considered trying the "Break on Error" option in the debugger?”

The first thing I did after I installed PBCC 4 was to tweak the ‘Options’. Your well thought out newsletter was fresh in my memory (I don’t mean the swap memory). The very first option I set was ‘Debugger Break On Error’.

On the other hand, I am disappointed that you give wrong answers to your own good questions:

“I guess not.”

Wrong, o wise one! You need some lessons in probability theory. Google on ‘Best bible probability theory’ (do not use ‘the’, ‘of’ or ‘in’ — Google will not tag them as errors, but the engine will ignore them; get it? Hey, smile for a change, o stiff one!)

The same difference — ‘Debugger Break On Error’ or ‘Debugger Break On No Error’…

Seriously, I almost miss PBDOS! Even if most errors it triggered were the kind of ‘Error 5 catch-all’, the compiler stopped at the EXACT line in the source code. I didn’t have serious problems figuring out what the real problem was. The precise erroneous line is what really matters. Who needs to dress up like the girly man?

IS IT TOO MUCH TO ASK TO GO BACK TO THE FUTURE?

posted March 14, 2005 06:32 PM            

But that aside, PB's compilers usually stops and reports the exact line
and position where an error occurs. If you forget a NEXT, that is not
an error in itself, but if next command is for example END SUB, you have
a missing NEXT and the compiler will indeed stop at the offending line,
which is the END SUB line. VB does the same. To compare, I just tested
the following in VB:

Private Sub Test()
For c& = 1 To 10
End Sub

VB points at End Sub and reports "For without next". I fail to see why
that is any better than PB's "NEXT expected", pointing at same position.
Have you actually tried this in VB yourself, before you "accuse" PB for
doing it differently?

Like I said earlier - if you have a specific complaint, please send a
compilable example to PB support so we can investigate.

BTW, since this is a PB/CC forum - how "easy" is it to create Console app's in VB.. ?

posted March 14, 2005 07:06 PM            

Why do you keep saying "Bitser". What do you think it means? I just googled it and this is what it came up with...

BITSER: A mongrel dog

Either you know something I don't or you are calling Bob Zale a mongrel dog?!

So PBCC acts a little strange the way you handle it, why not just learn to work WITH it.

Sigh...

posted March 14, 2005 08:46 PM            

Scott

posted March 20, 2005 10:48 AM            

I just upgraded PBCC to version 4.01. I have noticed some improvements in error handling.

If FOR is missing, the compiler stops and points to the correct statement: NEXT without FOR. I am really satisfied with that.

But if NEXT is missing, the compiler stops (good move!) and points to the next highest branch of the logical block. In the case I reported, the FOR/NEXT loop was inside an IF/END IF block. The compiler still jumps to ELSEIF. I am hopeful, indeed optimistic, that a new minor release of PBCC will fine-tune that feature as well.

The missing OPEN FILE statement reports the correct run-time error 52. The program did not continue as in my previous report, when it went on and created a file with wrong data in it. I think the compiler resets the program now, somehow like in PBDOS (‘Reset and run program’). I think that previously the… previous errors influenced the reporting of future errors. Possibly, the program was not reset before rerun.

At this point, I can affirm that PBasic is headed in the right direction, as far as error handling is concerned. I can expect future steps in the right direction.

I have never asked for a compiler to debug stupidity in programming. One of the members of this community preached me on good programming practices (e.g. code formatting). Incidentally, he sent me a bundle of his programs, including the source code. The programs were an exercise in programming stupidity. I have never, ever made such errors in programming, as the “preacher” did! No doubt, no compiler would ever be able to spot stupidity in programming! Needless to say, the precher’s programs did not compile; or, if they compiled, they did not run; or, if they ran, they did not run correctly!

The programmers love to program faster. Time is money. I don’t have to waste time being too picky with things like FOR/NEXT perfect pairing — and the likes. I also copiously copy-and-paste from my large library of source code. I don’t have to reinvent the wheel every time. But copy-and-paste can never be perfect. It’s another way of inducing errors in the source code of a program.

Again, I am satisfied that PBasic is headed in the right direction, as far as error handling is concerned.

WAY TO GO, BITSER! BRAVO, COPILE!

Ion Saliu,
Citizen Of The Error-Free World
www.saliu.com/infodown.html

posted March 20, 2005 05:38 PM            

FOR x = 1 TO 20
FOR J= 1 TO 3
LOCATE X,J*15
? FORMAT$(x,3)"-"FORMAT$(j,3)
NEXT z,i

This is legal code, but if you look at the NEXT statement,
you can see that PowerBasic indeed just closes the last
FOR NEXT and did not care about the variable names !

In Clipper and Xbase there is no chance to use NEXT for
two or more FOR statements. And it is legal to do this in
PowerBasic too:

FOR x = 1 TO 20
FOR J= 1 TO 3
LOCATE X,J*15
? FORMAT$(x,3)"-"FORMAT$(j,3)
NEXT
NEXT

I think that the first example should generate a FOR NEXT
error because a NEXT J could NOT ends a FOR X, but

using the second listing is the way I have to use it in
Clipper, Xbase AND PowerBasic.

With BRAIN ON its to handle

Maybe we will get a 'strong typed' version with compiler error
on the first example, but to write easier code is a good
solution up to there ...

Bye
Hubert

------------------

posted March 21, 2005 05:39 AM            

"PowerBASIC uses COUNTER with the NEXT keyword simply as a placeholder"

That is, a variable name following the word NEXT is, in effect, a comment for your personal use. The compiler does not use it nor check it in any way.

Regards,

Bob Zale
PowerBASIC Inc.

posted March 28, 2005 01:18 PM            

No comment.

posted April 01, 2005 02:43 AM            

So... since you've developed some code which makes error handling even better, why don't you share it with all the folks here? Many might be interested in seeing it?

Regards,

Bob Zale
PowerBASIC Inc.