I’m coming to Xojo from Python although I have a background in C# so I’m very comfortable in statically typed languages.
In Python, exceptions are cheap. They don’t use a ton of memory or processing power so they’re used to trap error conditions that in another language would be caught using more complex If…Then…Else or Select Case statements. Does Xojo follow this same paradigm? Is it generally frowned upon to raise exceptions for basic operations?
For example, in my desktop application I have a form and I’d like to raise an exception on a validation failure that returns a standardized object which can be parsed into feedback on the form. My inclination to use an exception is because a validation error is conceptually close to an exception; it’s an unexpected result that the system doesn’t know how to handle. Am I thinking about this the right way? I’ve looked around the forum and I haven’t seen anything about using exceptions as validation handlers so I’m wondering if there’s a better way.
In spite of being strongly typed, Xojo is extremely flexible, so you can probably make it behave the way you want. Although you cannot create exceptions, which limits probably the scope of exceptions usage for validation. I think it is way less flexible than methods, though.
If then else and select case are rather powerful ways of dealing with unexpected things, especially wrapped within methods. All depends on what you want to achieve. Without specifics, it is difficult to evaluate the benefits of each approach.
In this forum, you will find people of all backgrounds and schools, from the most psycho rigid dogma obedient personalities to some more inclined to unconventional ways. One thing is for sure : if you post an issue, you will quickly receive assistance, from all schools of thought, where you can pick and choose.
I tend to regard programming as culture : English is a vehicular language with a precise syntax and a finite number of words, yet among the billion tweets, some are dull, others are brilliant. So is programming. Our culture brings different styles of coding ; all obtain result, but with different flavors. Your Python origins will probably bring to your Xojo programming a distinctive structure. I engage you, though, to open the examples and look at the way they are built, rather than to try and translate literally Python listings. Just like a foreign language, you learn a lot more by speaking than by translating.
The first thing I recommend to people coming from another dev language: don’t try to make Xojo do it just like your old language. If you do, you will become increasingly frustrated.
If you try and learn the “Xojo Way” it will take you longer to learn but you’ll have a better project at the end.
After that, though, it’s pretty wide open. I know people who use exceptions - a lot - and some that do the bare bones minimum. One thing to keep in mind is that Xojo is starting a transition to a new framework that started with iOS and will eventually find its way into console, web, and desktop apps. The new framework uses exceptions with MUCH more frequency with the goal of failing early and failing loudly. The old framework not so much so you have to check for errors. Both ways works.
Using exceptions in the way you described is perfectly acceptable. I wouldn’t worry about the overhead, because they aren’t the norm and usually won’t come up that often. And, yes, you can create your own exceptions. Create a subclass of RuntimeException and you can raise and catch that exception in your code.
My apps usually have no try catch and just the unhandledException event. Coming from GWBasic and it’s infamous Onerror Goto, I learned long ago how to prevent rather than to count on them.
I did not know that. But it makes sense, since I seldom use them.
With the new framework we will al be doing more exception handling since that’s how they report errors. For some things it will be no big deal but for others it will be a pain. Database errors, for example, will now throw an exception which will require some thought on how to handle them - especially in transactions.