Can I get a return from ioexception

Getting Started
1

Can I get a return from ioexception?

I get API 2 deprecation error uhmm advice to change lasterrorcode to ioexception.
The reason I have them around is I would like to prevent Try Catch errors, and the way I do that is lasterrorcode will do a return.

In the LR it doesn’t seem that ioexception will do that.

Is there a way to do that?

2

Are you saying that you’re trying to avoid using try-catch at all?

3

No. I test when I assign the path to a folderitem (construct it) which doesn’t generate a Catch, because as Norm (?) wrote: it doesn’t do any work.

So, if I can get a return from Ioexception then my problems are solved.

4

What do you mean by “lasterrorcode will do a return” ? When do you want a return to happen?

5

if 100 = tObj.lastErrorCode Then
Where tObj is a folderItem

If I have just assigned the path to tObj then it will not, in my experience, generate a Try Catch, but I can test to see if it is valid.

I use this with stored paths in text.
If it isn’t valid, then the user can be alerted the file is missing.

6

Shouldn’t you be using

if  (tObj.Exists=False)  Then
// alert user
end if
7

I guess it’s just old thinking laying around.

8

My problem is converting old code like in this example
https://documentation.xojo.com/api/files/folderitem.html.CopyTo

At the very end of the “copyfileorfolder” example is this line which would be nice if it had a replacement in API 2
If source.LastErrorCode <> 0 Then
Return False

9 
Try
source.CopyTo (destination)
Return True
Catch err as IOException
// Alert user
Return False
End Try

The IOException gives you an error code too. I said “// Alert user” but that’s probably better done by the caller of this method, unless you want to log it right there (actually what I tend to do).

Or you might do both, that is log it to a log file when the error is detected (in the method), and do whatever else is specific to this call, higher up.

10

Unfortunately, there is no replacement (on MacOS at least). For most things, you can continue to use API 1 for a long time to come. One exception is FolderItem on MacOS, which had to be rewritten due to changes Apple made.

11

you could move this CopyTo into a extra method, this method have once a try catch
and return a string
return empty string “” as no error
or “error message/number”
see https://documentation.xojo.com/api/language/extends.html

its looks like
var lastErrorCode As String = tObj.MyCopyTo(destination)
if 100 = lastErrorCode Then

or if the method write into a global variable lastErrorCode
tObj.MyCopyTo(destination)
if 100 = lastErrorCode Then

its up to you what is best practice for your project update