When using the DesktopPopupMenu.SelectRowWithText method and the string is not found, an Exception is thrown.
Wouldn’t it be better to let it return a boolean if it found the string or not?
Now you need to handle an Exception which is not very nice coding.
Insert a module into your project and paste this code:
Public Function SelectRowWithText(Extends p as DesktopPopupMenu, Text as String) As Boolean
var Selected as Boolean = False
#Pragma BreakOnExceptions False
Try
p.SelectRowWithText(Text)
Selected = True
Catch e as RuntimeException
//Insert some other action here if desired
End Try
#Pragma BreakOnExceptions True
Return Selected
End Function
Now it will do what you suggested.
I would agree that it is peculiar, and it is not handled in a way characteristic of Xojo.
What advantage does a returned Boolean value have? If there is an exception, I put the whole thing in a try-catch and react accordingly if the string was not found. A Boolean value only gives me an indication that I have to react to a missing string…
Well, a boolean wouldn’t crash the app if you don’t surround the block with an exception handler. It results in less lines.
A simple event “UnhandledExceptions” prevents the app from crashing.
Not really in my use cases - with a boolean returned if have to go back to the place, where the popup is populated and decide which entry should be selected instead…
Exeption handling is MUCH slower and may leak memory.
Yes, there’s this too. A handle-all situations handler, and the following lines of code in the original method won’t execute. Still not better than handling a boolean/return value, IMO.
Can you give me a value what specifically means MUCH slower?
Hard to tell exactly how much slower but at least in my testing more than 10x slower and sometimes even more.
It is noticable for sure in loops for sure.
Yup. I have seen this, too, when testing different approaches to error handling.
I am not selecting any DesktopPopupMenus values in a loop, maybe this is the reason I’ve never seen any slowdowns, when a value is not available and the exception handling in my try-catch block is invoked…
Try-catch is, besides slower code and possible memory leaks, bad practice anyway.
The main reason why I think it is wrong with DesktopPopupMenu.SelectRowWithText is that no other Xojo control with similar method is handling this with an exception too.
This does seem like the wrong approach. What’s next, a version of InStr that raises an exception if the string isn’t found?
After API2, I will not be surprised anymore…
please . don’t . give . them . any . ideas
Just did a test on MacOS.
There is no noticeable difference in code execution speed. (both debug and compiled app)
Here’s my test code:
Dim start As Double = System.Microseconds
For i as Integer = 0 to 9999
PopupMenu1.SelectRowWithText("C")
PopupMenu1.SelectRowWithText("A")
Next
Dim elapsed As Double = ((System.Microseconds - start)/1000)
Dim start2 As Double = System.Microseconds
For i as Integer = 0 to 9999
try
PopupMenu1.SelectRowWithText("C")
Catch err
end try
try
PopupMenu1.SelectRowWithText("A")
Catch err
end try
Next
Dim elapsed2 As Double = (System.Microseconds - start2)/1000
Label1.Text = "SelectRowWithText x 10000 times" + EndOfLine + EndOfLine + _
"Without Try... Catch: " + chr(9) + elapsed.ToString(locale.Current, "0.00") + " milliseconds" + EndOfLine + _
"Using Try... Catch: " + chr(9) + elapsed2.ToString(locale.Current, "0.00") + " milliseconds"
Why would it be bad practice?
I can share multiple examples where Try-catch is absolutely necessary if you don’t want to break your app.
Try-Catch means you know something can go wrong and you are taking care of it in the correct way.
I wouldn’t say Try/Catch is bad practice, but it is not beginner friendly. I could see a new user to the language become stumped over this.
Eventually every Xojo user learns the necessity of try/catch but it requires a lot more effort than I think Xojo Inc would want beginners to have to put in.
If Xojo had checked exceptions they would be nice to work with. Without them you are basically programming in the dark as you have no idea if and what exceptions you might be dealing with.
At least when a function returns an error message, your code won’t compile unless you write code to handle or ignore the result.