I certainly hope not!
A search result of not found should not be an exception it is an expected possible result of a search… There are cases where you don’t know if something is there and you care checking if it is to decide what to do…
Using exceptions for that would slow down code needlessly (and under the hood speed should ALWAYS be a consideration if they want Xojo to be competitive) …
If API 2.0 throws exceptions for things that are really not exceptional like that, or causes overall causes your code to execute slower, API 2.0 will be received less well that the Xojo namespace framework!
Basically I am saying not to go overboard… Sometime being too ideologically pure gets in the way of productivity…too much of a good thing is not aways good… the right balance is needed.
[quote=436323:@Karen Atkocius]I certainly hope not!
A search result of not found should not be an exception it is an expected possible result of a search… There are cases where you don’t know if something is there and you care checking if it is to decide what to do…
[/quote]
reread my comment - I said IT MIGHT LOOK LIKE
Not it must look like
It was meant to be simple illustration of what code could look like
I have no idea if they will make IndexOf or whatever replacement throw an exception or not
I prefer a lot fewer deeply nested if’s where the “normal” code flow is just a series of statements one after the other and the error handling elsewhere rather than the error handling surrounding all the code I really want to focus on
you should say “it might slow down code” - not it WOULD
I expect that it wont slow it down but I dont expect you to know the details of why that is my expectation - thats way under the hood removed from most everyones view anyway
Joe would need to be around to do a long laborious explanation of zero cost exception handling
The only time it might be slower is when the exception happens - which should be unusual ; not routinely expected
[quote=436323:@Karen Atkocius]If API 2.0 throws exceptions for things that are really not exceptional like that, or causes overall causes your code to execute slower, API 2.0 will be received less well that the Xojo namespace framework!
[/quote]
only if you make a bad assumption about how exceptions work and the speed of handling them etc but …
[quote=436323:@Karen Atkocius]Basically I am saying not to go overboard… Sometime being too ideologically pure gets in the way of productivity…too much of a good thing is not aways good… the right balance is needed.
[/quote]
The complaints about the new framework effectively killed it despite all the things that it made much cleaner and made possible (like being able to do a better job of stripping out unused code in your compiled projects, better text handling with multibyte characters, and even the user of newer API’s for Folderitems)
So now we have API 2.0 which will, every time Xojo adds a new class, function, keyword etc possibly clobber your project because they’ve taken over something you used as a name in your code (which the new framework would not have)
Just like when statictext turned into Label and then everyone had to replace that in their code
I’m sure this can can happen to API 2.0 as well given enough time & effort & dedication
Today: An event occurs. Check if there’s a 0/ok/good/… result and if there’s none, check what kind of result it is and handle it. API 2.0: An event occurs. Check if there’s a 0/ok/good/… result and if there’s none, check what kind of result it is and handle it.
Until the moment it is checked for if something is ok, nothing changes. And therefore the performance should be the same.
As Norman said:
In short; Xojo will not check if this or that error occurred, but if everything went fine. And if it did not went fine, it will check what happened and throw the exception at you.
