Apr 21, 2017 Replies: 4 Had to put this together quickly, seems to work ok, just thought I'd share... Code: Sub GetSqliteVersion( db As SQL ) As String Try Return db.ExecQuerySingleResult( "SELECT sqlite_version();" ) Catch Log(LastException) Return "" End Try End Sub Click to expand...
Had to put this together quickly, seems to work ok, just thought I'd share... Code: Sub GetSqliteVersion( db As SQL ) As String Try Return db.ExecQuerySingleResult( "SELECT sqlite_version();" ) Catch Log(LastException) Return "" End Try End Sub
Erel B4X founder Staff member Licensed User Longtime User Apr 23, 2017 #2 I don't see any reason to catch errors here.
B B4JExplorer Active Member Licensed User Longtime User Apr 23, 2017 #3 Erel said: I don't see any reason to catch errors here. Click to expand... We can't imagine an error, because the sql statement is already confirmed. But we can imagine a developer sending the wrong sql object, perhaps one where the connection has been lost. I agree, it's unlikely Erel. But this is a just in case situation.
Erel said: I don't see any reason to catch errors here. Click to expand... We can't imagine an error, because the sql statement is already confirmed. But we can imagine a developer sending the wrong sql object, perhaps one where the connection has been lost. I agree, it's unlikely Erel. But this is a just in case situation.
Erel B4X founder Staff member Licensed User Longtime User Apr 23, 2017 #4 B4JExplorer said: But we can imagine a developer sending the wrong sql object Click to expand... In that case it is better to let the error "bubble up". It will be easier for the developer to fix. As a general rule you should avoid catching errors in libraries or utility methods and let the developer using the code decide how to handle errors.
B4JExplorer said: But we can imagine a developer sending the wrong sql object Click to expand... In that case it is better to let the error "bubble up". It will be easier for the developer to fix. As a general rule you should avoid catching errors in libraries or utility methods and let the developer using the code decide how to handle errors.
B B4JExplorer Active Member Licensed User Longtime User Apr 23, 2017 #5 Erel said: In that case it is better to let the error "bubble up". It will be easier for the developer to fix. As a general rule you should avoid catching errors in libraries or utility methods and let the developer using the code decide how to handle errors. Click to expand... Will do. Actually, I never liked Try-Catch. It gets in the way of clean code, and makes error management more complicated than it has to be. GoLang is on the right track.
Erel said: In that case it is better to let the error "bubble up". It will be easier for the developer to fix. As a general rule you should avoid catching errors in libraries or utility methods and let the developer using the code decide how to handle errors. Click to expand... Will do. Actually, I never liked Try-Catch. It gets in the way of clean code, and makes error management more complicated than it has to be. GoLang is on the right track.