Sorry your browser is not supported!

Why is it not a good idea for the compiler to output all the compiler errors it finds in a list, leaving the programmer to rectify all errors, including those which cause additional errors?

Probably because it gives up parsing the code as soon as an error is found.

Compilers that do keep on checking usually report lots of subsequent errors to the first one. If you forget a semicolon in C++ you can end up with 200+ syntax "errors" that all go away if you fix that first little fault...

The reason for this is of course that the compiler cannot guess what the code would look like if it was correct. Or well, it could, but then you'd have the much worse problem that the code it guesstimates you were trying to write might function differently from the code you were actually failing to write correctly.

It all depends upon what kind of errors being found as to how effective this is. A syntax error in some operation/function/command statement is one thing, but when errors occur within a structural statements, this behavior tends to create cascading long list of faults. We tried a few variations of this in PB, but our case just opted to make the compiler quicker.

Yeah, that is what Microsoft Visual studio does with C# and VB; although that is probably a CLR interpreter feature. You get a list of all the errors found; then you can correct the errors in order of occurrence, which usually points you to the root cause, which often eradicates most of the errors at the bottom of the list.



Things like missing colons are not an issue in DBP; but I understand your point, this is where error categorization could help. The compiler could bypass erroneous functions or blocks and validate the next and output this to a log; the first error would still the main one, the one that displays in the message box.

I can't see why this wouldn't be a good optional feature; it may even help Lee finish FPSC reloaded more quickly. lol.

Thinking of compiling many 1000s of lines; actions that are related to syntax and typing errors would generate a huge list; but why not highlight the first error found and list the other errors in a seperate list; one can correct the main mistake while the program is still compiling, and spot typing mistakes and plugin/core parameter errors and correct them as you go.



True it has less work to do if it only works up to one error; but would the task take more time and effort if say a 5 minute compile of 30-40k lines made obvious which error is the first one, and what categories each error fall under; warning, parenthesis error, parameter error, type field error, etc. rather than doing the compile job waiting for it to spot one error? I would have thought that would save more time, but you found it to be more problematic?

I guess this it is common practice to report one error; creating an optional error list feature would be quite bold.

Returning multiple errors isn't any more difficult. The parser breaks down into a single loop really that exits when the error state is set. To return more than one error, just add the error messages together, flush the state and continue on. There needs to be maximum error count though.

The only negative is cascading errors become more likely, where say error #1 is causing error #2 and so on down the line. These generally occur as a by product of some structural mistake, which should force an exit anyway.

ie.



So a missing closing statement like this, ends up spiting out every line thereafter as an error. Which can be pretty annoying.


It works much better for stuff line this though,



Say a programmer adds the d parameter to this function and re compiles, now each call of the function will pop out some type of parameter mismatch in the error list. Which is pretty handy.




40K lines is only 4->5 second build time, even in legacy PlayBASIC, so thankfully we don't have that problem.

I'm quite happy with the compiler stopping at the first error for the reasons stated - but I can see that can be a pain if there are in fact several errors a long way in to the code of a very large project so that you have to wait ages for each compile to spot errors individually.

In years gone by I used to be infuriated by compilers that would spend ages spewing out false alarms when all I wanted to do was fix the first bug (which often unhelpfully scrolled out of view before you had a chance to read it). Working with DBPro is simple by comparison. There was sometimes an option to output the error messages to a file which you then had to open just to be able to read the first crucial error message. Sometimes simplicity is, well, just simpler.

My experience with coding errors though is that one error often alerts me to the likelihood of several related subsequent errors so I can check for those before doing another compile.

Another worry about getting the compiler to look for further errors is that to be useful it could take a lot of development time just to get that part of the compiler right when in fact time could be spent more productively.

On balance I'm happy to leave this issue to TGC to decide on.

Wow what a good life PlayBASIC users have.



Yeah, false alarms can be frequent; and I suppose it makes things more complicated for new users.

I would have made it an advanced option; I'd only display the actual error message as it is now the main body of the error log, then list the other possible errors in an advanced log file which IDEs can display in a separate console. 10 non related basic mistakes * 5 minutes compile = 50 minutes of time instead of 5 minutes. The thing is, you'd have to be pretty sharp at recognizing false errors; which I have no problem with because I compile all the time and backup all the time.



Yeah; for most people compile times is not high priority it seems; I'd be the odd one out. I am creating the high level logic outside of DBP anyway to reduce the number of compiles necessary for tweaking.