Yes, it’s a very daring title, but after all, in reality, in the code, what has changed with API2?
The list of commands? Yes, and some code here or there.
So, SQLExecute becomes ExecuteSQL, but nothing (or so little) has changed in depth …, in the IDE code.
Compare the size of the Xojo 2019r1.1 application to that of Xojo 2019r3 (I did not download the Xojo 2019r3.1 version). The difference is very small.
You can share your opinion here.
SQLExecute sets error property.
ExecuteSQL raises exception on error.
This is a significant change!
Exceptions vs LastErrorCode is significant. Zero-based array indices vs a mixed bag is significant. There’s a lot about API 2.0 to like regardless of file size (not sure what that has to do with anything?).
I can’t explain it really, but with API 2.0 i suddenly write cleaner Code. I think this is because of the move from ErrorCodes to Exceptions. I now really like API 2.0. 
Exceptions for these sorts of methods is a backwards step, IMO. Still, I work around it in my wrapper, where I do a try/catch and save the error code there. So no difference in the end,
Still, plenty of other things to like in API2, although there are still some missing methods.
[quote=474033:@Tim Streater]Exceptions for these sorts of methods is a backwards step, IMO. Still, I work around it in my wrapper, where I do a try/catch and save the error code there. So no difference in the end,
Still, plenty of other things to like in API2, although there are still some missing methods.[/quote]
Why do you think it’s a backwards step @Tim Streater ?
No, the IDE change from RealStudio to Xojo was the greatest swindle. There is almost nothing that isn’t better in the lovingly-crafted RS IDE, imo. After spending the last 5 years trying to be a good soldier and adapt to Xojo, I recently went back and did a project in RS2012. Omg, what a breath a fresh air.
Agreed. Exceptions make the language unfriendly. I’ll take error codes over exceptions any day. Even worse, URLConnection error codes are different depending on the target.
Better or not, the question was about the extent of the changes.
Exceptions are great if the error condition is indeed an exception. You can write clean code that relies on everything going smoothly and deal with error conditions separately in an exception handler. If however errors are par for the course then returning error codes and dealing with these within the main control structures should be preferred.
Swindle (noun): fraud, trick, deception.
Ignoring this conversation.
[quote=473999:@Christian Schmitz]SQLExecute sets error property.
ExecuteSQL raises exception on error.
![/quote]
ExecuteSQL probably just wraps SQLExecute and checks the error code and raises an exception
Exception handling in Xojo is zero-cost when you do NOT execute the exception handler - but overall exceptions are much slower esp if you expect to have to handle a lot of errors
So even if all you want to do is ignore the error code / exception your exception based code will be slower
If you have a mathematical function such as sqrt() or arcsin(), then if these are given invalid argument values I would expect an exception, since there is no useful means of handling an error code. I wouldn’t expect a programmer to split up a complex mathematical expression.
But, for many functions, an error case (e.g., file not found) is a perfectly reasonable result to get and I don’t expect to get an exception for such things. Equally I don’t consider invalid UTF8 data a reason for an exception when trying to convert it to something else. Why? because the remote end which sent me the byte string and claimed it to be UTF8 could have lied. So I consider the handling of such invalid data to be a normal operation.
Having said that, by and large it’s been easy enough to work around. I’d be interested to hear other, differing, opinions on the matter, although any which invoke “modern” or “uptodate” I shall ignore.
That is not necessarily due to API 2 per say, but Xojo Inc deciding it was not worth the effort to return X-platform Error codes when they make sense when using platform specific underpinnings.
For a product for which the main selling point is ease of doing X-Platfrom apps, that is unfathomable to me.
IMO they either needed to make that effort or use an X-Platfrom library underneath… the API and error codes we see (as well as behavior!), as much as possible, should NOT depend on platform. That is PARTICULARLY so IMO for non UI stuff.
That should be priority #1 for Xojo inc. for whatever they implement.
-Karen
I’ve advocated for years that the database classes should throw exceptions on SQL errors. Why? Because I’ve fixed so many projects that don’t check for the database error that I’ve blogged about it pretty consistently. Plus, people coming from other languages often expect the exception to be thrown and it’s not.
Exception Handling is kind of a pain, but it’s better to know with 100% reliability that you know there is an error rather than having Recordsets return nil and not know why because the developer didn’t check for the error. The old way meant the developer didn’t often know their SQL was bad and it led to really, really poor code (i.e. check for nil RecordSet) rather than handling it and getting feedback to the user/developer.
API 2.0 is NOT about being modern or up to date. It’s about being consistent and for the most part it is. I think we all disagree on some of the naming conventions they decided on but it is consistent. Don’t get me going on throwing away 20 years of examples and documentation and training videos though…
In some cases exceptions are preferable while in others error codes are better. For example, if you have a method where you are setting up a database I would prefer using exceptions while setting up the folderitem and associated database file itself. But when creating the tables, having error codes is easier. Consider the following,
[code]// Create the tables for the database
theDB.SQLExecute (“CREATE TABLE Items (ID integer NOT NULL PRIMARY KEY, Item varchar, Genre varchar)”)
If theDB.Error = True Then
DisplayError(False, CurrentMethodName, 2)// there was an error with the database
Quit
Return
End If
theDB.SQLExecute (“CREATE TABLE Notes (ItemID integer PRIMARY KEY, ItemNotes varchar)”)
If theDB.Error = True Then
DisplayError(False, CurrentMethodName, 3)// there was an error with the database
Quit
Return
End If
theDB.SQLExecute(“CREATE TABLE ItemPhoto (ItemID integer PRIMARY KEY, ItemPhoto blob)”)
If theDB.Error = True Then
DisplayError(False, CurrentMethodName, 4)// there was an error with the database
Quit
Return
End If[/code]
In this case, using error codes is logical and lets the app tell the user exactly which operation threw the error. Using exceptions requires either that each operation is in its own Try-Catch block or some other means of identifying each operation when an exception is thrown. For example, you can use a variable to identify the location and report that in the error message in the Catch section.
[code]Try
locStr = “Creating Items table.”
theDB.ExecuteSQL (“CREATE TABLE Items (ID integer NOT NULL PRIMARY KEY, Item varchar, Genre varchar)”)
// Item Notes
locStr = “Creating Notes table.”
theDB.ExecuteSQL (“CREATE TABLE Notes (ItemID integer PRIMARY KEY, ItemNotes varchar)”)
// Item Photo
locStr = “Creating Photos table.”
theDB.ExecuteSQL (“CREATE TABLE ItemPhoto (ItemID integer PRIMARY KEY, ItemPhoto blob)”)
Catch err
DisplayError(currentmethodname, err.Message, LocStr)
End Try
[/code]
Either way will work (allowing for my untested code) so a lot depends on what you particular needs are and which you prefer to use. (The DisplayError method is left as an exercise for the reader.)
As I said elsewhere I find that constancy over done when it is applied to things that are different in kind in a significant way… it makes code harder to read/understand at glance for me.
When I see AddRow for example, i think UI element etc.
container controls as control set would be consistent.