The code below works on my dev machine but errors on production

Targets Linux
1 
If myDocs <> Nil Then
  Var file As FolderItem 
  Var sDate As String = modSysWide.mthDate( )
  sSystem = sSystem.Trim
  
  If( sSystem = "LinuxSysA1" ) Then
    file = GetFolderItem( "/home/ian/Development/My Apps/Meters V2/Reports").Child( "Proposal " + sTitle + " - " + sDate + ".csv" ) // Dev machine...
  ElseIf( sSystem = "Meters-1657" ) Then
    file = GetFolderItem( "/home/Meters/Documents").Child( "Proposal " + sDate + ".csv" ) // Prod machine...
  Else
    MessageBox( "This function cannot work as you are not on a validated system." )
    Exit
  End If
  
  If file <> Nil Then
    Try
      // TextOutputStream.Create raises an IOException if it can't open the file for some reason.
      Var output As TextOutputStream = TextOutputStream.Create( file )
      Var finData As String = Join( sOutput, EndOfLine.UNIX )
      
      If( output ) <> Nil Then
        output.WriteLine( ConvertEncoding( finData.ToText, Encodings.UTF8 ) )
        output.Close
        MessageBox( "Base proposal file created." )
        mthSaveProposal( )
        MessageBox( "Core files saved to database." )
      End If
    Catch e As IOException 
      // handle
    End Try
  End If
End If

The development machine is Kubuntu Linux and the production machine is Trisquel, I checked to make sure the target folder permissions were correct and they are. I have no idea how to fix this. All the code up to this point executes just fine. I have another module with a similar set-up and also throws an OutOfBounds Nil Object error.

2

Well, what error do you get and where?

Add some logging with system.debuglog so that you can see what happens in production which is different from debug. Also, if you do

if myDocs = nil then return

then your code becomes much easier to read.

I would change the file <> nil line to something like

if file = nil or not file.exists then
 Messagebox("error here")
 return
end if
1 Like
3

Exception of Class NilObject was not handled.

What has me puzzled is the program works on the dev machine but throws this error on the prod machine. I’ll try your code suggestion and see what comes of that. Thank you!

4

You might try putting the remote debugger on the production machine and then running your project there remotely. The debugger will stop on the exact line where the problem is.

2 Likes
5

This is not declared on the shared code.

What is modSysWide (not declared too).

I do not like this construction because you cannot know if there is an error on the path:

file = GetFolderItem("path").child(…)

Sorry: GetFolderItem is deprecated (dixit the documentation but not theIDE ?

I pasted your shared code and get tons of errors…

In short:

I tend to do not concatenate instructions in a single line to add readability and have clean error report (when that arise).
Or, when an error is in that kind of line, I split it immediately (that helped me in the past).

6

When I have issues like this there are two approaches to take…

  1. Add copious amounts of logging to output to the console or a file so you can figure out which line it’s failing on

  2. Use the remote debugger to locate the exception in the IDE

7

modSysWide is where I keep global methods I can use anywhere. I didn’t realize GetFolderItem is depreciated. So I will check to see what has replaced it.

So it appears there are big changes on how to write a file out. So more reading apparently.

8

OpenFileDialog class

1 Like
9

One option is to use an IDE script like this to track the current line number in an App.debugLine variable.

Then in the App.UnhandledException event, you can display a message box with that line number.

Debugging Line Numbers App.xojo_script.zip (1.2 KB)

To use it, you can put that xojo_script file in the Scripts folder next to the Xojo application. Then you just go to the method that you want to log and run the script from the File menu.

Running it again will remove the code that it added.

1 Like