How to keep list of error code and messages in the program

Sorry, the title may be not so straight forward.

I want to keep a list of error code and messages with in the program, and not in database or external file.

My initial approach was to create a struct with error code and error message and save it as a constant with dictionary data type.

Unfortunately constant can only be set to primal data type such as integer, string, boolean & text.

The only way that I think can be done is to create a computed property in a class where I will have to set all the structure values by code.

Would there be a elegant way to implement this?

Maybe constants or a dictionary.

I just said that the constant does not work.
How are you implying to use a constant?

A constant for all the error messages?

What do you want to do with your list?

Make a class with the properties you need and then make a manager for the properties class. You don’t need to use constants.

The answer to this question will change the implementation options.

Do you want the list of errors to show in the IDE using autocomplete or just use them at runtime?

[quote=489796:@]The answer to this question will change the implementation options.

Do you want the list of errors to show in the IDE using autocomplete or just use them at runtime?[/quote]

The former.

[quote=489793:@Beatrix Willius]What do you want to do with your list?

Make a class with the properties you need and then make a manager for the properties class. You don’t need to use constants.[/quote]

Meaning I have to create a property for all the error codes. Correct?

Have you tried creating a global Module and having the error codes as Constants with the default string value as the message?

I suppose that is the best solution so far. I wanted to use the struct, but no luck.

Show us your code.

i would use a module with constant as example
name errorfilenotfound
string = “4711:file not found”
you have number and info in one and the method that show this error could split the number and value if necessary.
and you have the option for localization.

and for other error you can store/output the exception object.

documentation.xojo.com/api/exceptions/raise.html
documentation.xojo.com/api/language/runtime.htmlException

I’ve seen it done where to stay in the concept of Exceptions for Errors, the developer had created several subclasses of RuntimeException that set their Message property in the constructor.

I don’t tend to do it that way, but I do use lots of RuntimeException subclasses in my error handling designs.

[quote=489933:@Tim Parnell]I’ve seen it done where to stay in the concept of Exceptions for Errors, the developer had created several subclasses of RuntimeException that set their Message property in the constructor.

I don’t tend to do it that way, but I do use lots of RuntimeException subclasses in my error handling designs.[/quote]

This would be the correct way, but managing the all the exceptions in Xojo IDE is not so easy to maintain.

You could create a module to manage your specific exceptions with functions for creating new ones. This would give you the autocomplete functionality you likely desire. For instance, I might have a module called ProjectExceptions with a method called BadColorException that I can use if a user selected two colors that are too close together in cartesian distance, or might be hard for a color blind person to make out. This would, in turn, instantiate a new instance of my RuntimeException subclass called BadColorException.

I’ve created this example for you to look at.

Note that my example is just one method, and not a great one, for doing this. You could just as easily do like @Tim Parnell said and override the constructors of the RuntimeException subclasses that you add to the module for the same effect with the following code:

var newException as new ProjectExceptions.BadColorException

[quote=489968:@Anthony Cyphers]Note that my example is just one method, and not a great one, for doing this. You could just as easily do like @Tim Parnell said and override the constructors of the RuntimeException subclasses that you add to the module for the same effect with the following code:

var newException as new ProjectExceptions.BadColorException

In the message in constructor design, the developer was doing this:

raise new ProjectExceptions.BadColorException

Which is really clever, but doesn’t offer specifics so it’s a cost-benefit judgement.