Debug option

Spire_Jeff

Is there an option to have the debugger break on an error? I am referring to errors like index=0 and other internal errors.

Right now, I just grab the line number, then do a find in files, then try to find the line number that matches the error. It would be a little easier if I could just have it break on an error and point me to the offending code

Jeff

ericmedley

I don't think so. I typically Telnet in and do the 'msg on all' command for this kind of thing. things like an index=0 error are accompanied by a line number and file reference. Having both helps me find the offending code quite fast.

I've gotten into the habit of trapping zero index probabilities myself as a result. I don't put in traps that are setup in button events where a zero index errors are not probable. But do them in data_events where the strings can get goofed up and whatnot.

I suppose the added IF statements are kinda processor 'spendy' but it does keep the run time errors to a minimum.

Colzie

I routinely turn on diagnostics while developing my code to check for these types of errors. I agree, it would be nice to be able to have the debugger stop the program when it found these.

jason_the_adams

It would also be great to introduce error handling code such as:

Try (Something) {
     Catch(Error type) {
     }
     Finally {
     }
}

The ability to catch and handle errors and exceptions within runtime is an awesome ability found in other languages that really makes the difference between a well programmed job and software written to run naught but ideally (in other words, short-sighted programming).

DHawthorne

jason_the_adams wrote: »

It would also be great to introduce error handling code such as:

Try (Something) {
     Catch(Error type) {
     }
     Finally {
     }
}

The ability to catch and handle errors and exceptions within runtime is an awesome ability found in other languages that really makes the difference between a well programmed job and software written to run naught but ideally (in other words, short-sighted programming).

It also adds a considerable amount of processing to the system, which is why most also include a flag to shut it down when you are fully debugged. AMX has such a flag as well, but the debug environment is considerably less able than, let's say, Visual Studio's. I would be willing to bet a decision was made somewhere along the line, that since the primary objective was to actually control a hardware device, not invent a full-bodied programming language, that it was in their best interests not to go any farther down that road than they had to and remain functional. IMO, they need to go just a bit farther than they have, but I don't think they need the full range of debugging a commercial programming environment has.

jason_the_adams

DHawthorne wrote: »

It also adds a considerable amount of processing to the system, which is why most also include a flag to shut it down when you are fully debugged. AMX has such a flag as well, but the debug environment is considerably less able than, let's say, Visual Studio's. I would be willing to bet a decision was made somewhere along the line, that since the primary objective was to actually control a hardware device, not invent a full-bodied programming language, that it was in their best interests not to go any farther down that road than they had to and remain functional. IMO, they need to go just a bit farther than they have, but I don't think they need the full range of debugging a commercial programming environment has.

I'm not sure to what extent I really agree with your conclusion. I understand what your saying, but honestly I find a processor is rarely pushed to its limits - if it is, then something is wrong or the system was poorly coded. It was far easier to overload a system in the days of BASIC and whatnot, where all of code was treated as the Netlinx Define_Program section - perpetually running through each line. But in event programming there isn't nearly so much of a problem - as the vast majority of the code isn't even being considered by the processor until an event leads it to do so.

So I guess my thinking is: having the feature of the language available won't necessarily bog down the processor too much in and of itself; properly integrated debugging code shouldn't add too much weight, and would give incredible capability for creating a more reliable system.

Edit: Furthermore, I don't necessarily think that the debugger needs to be more powerful, but more opportunities for runtime error handling code.

DHawthorne

We probably agree more than not, I was just throwing that out there .

jason_the_adams

DHawthorne wrote: »

We probably agree more than not, I was just throwing that out there .

Probably true and I appreciate it; any further disagreements can be settled via thumb-wrestling.