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.
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.
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.