Self Made Compiler Errors?

ID:151319
 
Aug 9 2011, 7:59 am
While working on a bit of my Library, I realized something that would help debugging by a factor of 10! If developers could actually create their own custom compiler errors to tell them when a piece of code is out of specific bounds or doesn't add up correctly. I would say that this is better to use as a pre-run suicide check. Say if two values are not equal, the compiler reads that and prints out a corresponding error message.

Most people hate compiler errors and wish they would just go away, but I find them infinitely useful when tracking down particularly pesky problems. The only thing that would make it easier would be if I would define my own, to make sure my code has a much less chance or generating bugs at runtime.

How this would work, I guess would be such as a simple if() statement. It works like regular DM code but is read through when compiled. It takes this new error and checks the .dm files for anything that breaks the custom errors new rules. A simple definition of a compiler error might be placed into the .dme file, and could look something like this:
#define_comp_error //defines a new compiler error
{
   DefineVar("apple", 'example.dm', /mob/tree/var/apple) //a built-in proc that takes three args, the first argument is the name of the newly defined compiler variable, the second is the .dm file to look through, and the third is the type path for the variable in question.
   if(!apple) //If apple is null or 0
      COMP_ERROR("var/apple much be a non-zero number") //This other built-in proc would output the message in the message box and points to the line where apple has ever equaled 0 or null.
}


I guess while you're making a custom errors message, you can also do warnings as well. Multiple Variables could be defined and checked either individually or against one another.

This would be very tricky to incorporate user-defined compiler errors, but if it could be done in a practical way, It would be an invaluable tool for developers. All developers make accidents in code, if they accidentally make a variable 0 that wasn't supposed to be, this could point out their mistake before really big problems arose. Does anyone else have any thoughts on the usefulness that this tool might bring?
Aug 9 2011, 10:04 am
You can somewhat do this with #if and #warn.
I use it to check if #debug mode is defined or not so I don't forget to turn it off before packaging.

#define DEBUG
#if defined(DEBUG)
#warn DEBUG Mode is on.
#endif
Aug 9 2011, 10:30 am
In response to Oasiscircle
Hmm, when whenever I attempt that approach all it does is delete anything I've changed. If I try it in a .dm file, It merely gives me errors because of the statements being their, not because of the string.
Aug 9 2011, 1:50 pm
Let me get this straight. You want to be able to check if a particular variable of an object in the DM code tree is defined or not? (e.g. in your example, the 'tree' has a var called 'apple' and you want an error if it's not defined with an initial value.)

This reminds me of a couple of things in C++: virtual inheritance (force a method to be defined with an abstract class), or reference member variables (must be defined in the constructor).

Of course, you could easily make a run-time error that only happens when debug is defined. (Using #ifdef and the CRASH proc.) You would basically put that in the New() proc of the object.

Other than that, if you really want to do this, you should probably submit an actual feature request.
Aug 9 2011, 4:39 pm
In response to Complex Robot
Complex Robot wrote:
Let me get this straight. You want to be able to check if a particular variable of an object in the DM code tree is defined or not? (e.g. in your example, the 'tree' has a var called 'apple' and you want an error if it's not defined with an initial value.)

Not an initial value exactly, it could be simply making sure that a variable doesn't fall out of certain parameters, say between 10 and 30. If the variable is ever manually defined outside of this range, it sends an error. It keeps accidents from happening.

This reminds me of a couple of things in C++: virtual inheritance (force a method to be defined with an abstract class), or reference member variables (must be defined in the constructor).

I have minimal C++ Experience, but I know what you're getting at.

Of course, you could easily make a run-time error that only happens when debug is defined. (Using #ifdef and the CRASH proc.) You would basically put that in the New() proc of the object.

Other than that, if you really want to do this, you should probably submit an actual feature request.

I was wanting to see if this would be useful to others before going as far as to submit it as a feature request. If it's not something people would use often, I would rather not bother the BYOND Dev team with a mildly pointless addition to the syntax.
Aug 9 2011, 5:29 pm
In response to Danbriggs
Danbriggs wrote:
Complex Robot wrote:
Let me get this straight. You want to be able to check if a particular variable of an object in the DM code tree is defined or not? (e.g. in your example, the 'tree' has a var called 'apple' and you want an error if it's not defined with an initial value.)

Not an initial value exactly, it could be simply making sure that a variable doesn't fall out of certain parameters, say between 10 and 30. If the variable is ever manually defined outside of this range, it sends an error. It keeps accidents from happening.

This reminds me of a couple of things in C++: virtual inheritance (force a method to be defined with an abstract class), or reference member variables (must be defined in the constructor).

I have minimal C++ Experience, but I know what you're getting at.

Of course, you could easily make a run-time error that only happens when debug is defined. (Using #ifdef and the CRASH proc.) You would basically put that in the New() proc of the object.

Other than that, if you really want to do this, you should probably submit an actual feature request.

I was wanting to see if this would be useful to others before going as far as to submit it as a feature request. If it's not something people would use often, I would rather not bother the BYOND Dev team with a mildly pointless addition to the syntax.

For what you're talking about specifically, I made a library to combat these things. I'd need some other examples of how this can be used, because I can't really see it being too useful.

Anything you want the compiler to do, though, is probably best done in a code, put in it's own datum, like I did.
Aug 9 2011, 11:53 pm
In response to Danbriggs
Well, DM already has an ASSERT proc. (Which you could use to check if any sort of values aren't what they're supposed to be.)
However, this is still at run-time.
Aug 10 2011, 5:47 am
It seems weird to define compiler errors in DM using DM inside the DM code file that is being compiled by DM and subjected to your custom DM compiler errors. It's also not clear how this would work for anything more complex than enforcing bounds on a value. If you want to just enforce bounds on variables, there'd be an easier way to add this feature (you wouldn't need the whole DM-like language for defining the bounds).

Run-time is the way to go. Have some code in your library that checks values as the game is running and reports bad conditions. Have the code inside of #ifdef blocks or contained in a single file so users can easily compile the library without the runtime debugging features.
Aug 10 2011, 10:32 am
In response to Forum_account
Hmm, Well the original idea wasn't limited to solely restricting values of numbers, but it seems the original purpose has escaped me at last. I believe this original thought stemmed from my study on compiler building with C++, which I guess would have been user defined syntax, however that's what procs are for. Oh well, the last fire of my idea dies without me being able to recall my original idea, a bit disappointing...