Bug not trapped by Try…

General
1

The example below demonstrate that, if there is already a text file with that name at the destination.

Try // TextOutputStream.Create raises an IOException if it can't open the file for some reason. Dim t As TextOutputStream = TextOutputStream.Create(f) t.Write(ConvertEncoding(TextField1.Text, Encodings.UTF8)) t.Close Catch e As IOException // handle End Try

The crash (in the running IDE) happens on the TextOutputStream.Create(f). The error is a Nil exception.

My real code is “based” on the LR example above.

2
  • are you running this compiled? or in the IDE?
  • do you have “Break on Exceptions” turned on
  • TextOutputStream.Create(f) will always over-write a file if it has permission
3

You’re trapping an IOException but getting a NilObjectException - something is nil, no?

4

perhaps “F”

5

IDE

Standard. (unchanged from default)

The file is locked, so it cannot overwrite.

Now that hours ellapsed, I realized that it is my fault: I do not checked Locked… :wink:

I was so surprised (the error was to lock the file; I’d better do as usual: make a copy of the files and use them as replacement instead of licking them…) that I said loud: “It’s a Bug” (my code, the LR example code crashed !) …

Also, Juilia is correct: I do not trapped the correct Exception.

So, thank you for your answers, forget this converation and have a nice Sunday all !

Nota: I use this code example since… the down of times :frowning: or :wink:

6

I’m guessing that “t” was nil because it couldn’t be created.

7

Emile, by default the debugger will stop at the line that causes an exception unless you have Break On Exceptions turned off. What you are seeing seems to be the correct behavior. If you press Resume or step through the code, it should continue through a Catch e as NilObjectException block, assuming you had one. What you are seeing does not indicate that there is a bug in Try/Catch. It appears to be normal debugger behavior.

8

And it cannot be created because I locked the existent file (I do not wanted to retype its contents).

@Tim Hare:
I was so surprised to get and error (Nil…) … I do not think “why” ? but: it always worked fine !

What a strange idea to lock a Preferences file ! :frowning:
Usually, I made a copy to avoid retyping its contents at debug times. :wink: