-2

I have code similar to:

with open('folder/file.txt', 'w') as file:
    file.write(json.dumps(someJsonData))

In my program, each instance has a user. This particular code is inside a loop that edits the data files of multiple other users and always the current user with is code. The code works fine on the other users, but the current user's file never changes, even though I can verify that it did run and that it gives no error messages. Considering that I have opened and closed this file before in the program, I could have forgotten to close it, but I can not find a place where I did not (I did not use a with the entire time to open a file).

Once before I had a similar issue in a different language and was able to print a hidden error message.

Is there a way I could print every output of this bit of code? For example, it might say "Successfully wrote to the file", or "Warning: Could not open the file". Could you do some sort of try-catch thing to always get a printable output?

Jack
  • 1,893
  • 1
  • 11
  • 28
  • 2
    Can you explain what you mean by _" it won't update the file, even though it is writing to it"_? – Selcuk Oct 08 '19 at 23:54
  • @Selcuk This opens a user data file. The way this program is set up, each instance runs as a user. This code is in a loop that edits the data file of multiple other users and always the current user. It has no issue updating the other user's files, but will never update the current user's file, even though I have it printing the content it's going to write right before and gives not error after. I was hoping that there would be a way to see if there was a "hidden error", even though the error could be somewhere else. – Jack Oct 08 '19 at 23:59
  • 1
    There are errors for non-existent files, invalid permissions, I/O problems, etc. Python is big on not doing "hidden" things. The error is with 99.999999% certainty on your end. You're either looking at the wrong path, have empty data, or something similar. We can't help diagnose implausible assumptions. We need a reproducible example. – Mad Physicist Oct 09 '19 at 00:08
  • Please ask an question that actually reflects the exact problem you are experiencing and exactly how you know there is a problem - not how you think it needs to be solved. Try to make a short, but complete example that someone else could run on their computer, step by step following your instructions, and observe the problem you have in mind. – Karl Knechtel Oct 09 '19 at 01:12
  • @KarlKnechtel, thank you, I'll keep that in mind. I was able to fix my issue indirectly with help from Nick's answer. I tried to delete this question because it's not a very good one for the reasons you mentioned, but StackOverflow wanted me to keep it because there was already an answer posted. – Jack Oct 09 '19 at 19:23

1 Answers1

1

As far as I can tell, no.

None of the functions you've named in your post return extra information or hidden warnings; to diagnose it further, we would need to see your actual code. There are a few things you might want to try, though.

  • .write() returns the number of bytes it has written; this can be checked against expected output to make sure the file is receiving the appropriate amount of input.
  • open() has the option of specifically handling encoding errors, but the default is to raise a ValueError, so if you aren't getting an error now, changing it may or may not help you out.
  • Check to make sure the file you're trying to write to wasn't accidentally opened in read-only mode somewhere else, or isn't being written when you check it - user data files are often culprits in this case.
  • Make sure the file is being closed properly. If you're using with, it should close automatically, but I believe I remember reading that python isn't guaranteed to write its buffer unless close() is called. (This happens behind the scenes when using with, once you go out of scope.)
Nick Reed
  • 4,989
  • 4
  • 17
  • 37
  • Thanks for your answer, just to clarify, by read-only you mean `f = open('path', 'r')` and then using `f` again and not doign `f.close` first? – Jack Oct 09 '19 at 00:16
  • I was more referring to a file being opened in another program that would put an editing lock on it, OR to one program opening multiple pointers to the same file, i.e. `f = open('path', 'w')` and then later `g = open('path', 'w')`. Since each instance of `open()` is given its own file pointer, I imagine calling `.close()` on one might easily clobber the edits of the other. Opening multiple pointers to the same file with any language, in any way, is a headache often best avoided. – Nick Reed Oct 09 '19 at 00:25