[R.....y]

#naukaprogramowania #programowanie #python

Mam bardzo prostą metodę w klasie:

 def save_to_file(self, path):
 try:
 with open(path, 'w') as file:
 file.write(json.dumps(self.data, indent=4))
 except PermissionError:
 print(f"no permissions to save the file in {path}")

Chcę odpalić unit test:

 def test_write_to_file_without_permissions(self):
 d = data_getter(LoadFromFile=True, data_path='data.json')
 self.assertRaises(PermissionError, d.save_to_file, 'no_permissions_to_write/data.json')

Problem jest taki, że jeżeli zostawię blok except w metodzie, to wtedy unit test go nie łapie. Jeżeli wyrzucę nowy error w bloku except, to zaliczam test, ale sam program wtedy się będzie wywalać.
W jaki sposób mogę zachować block except, żeby test case wykrywał że dostałem w ryj wyjątkiem nieobsłużonym?

[Saly]

@RedveKoronny:

 request = json.load(sys.stdin)
url = "[https://api.steampowered.com/ISteamUserStats/GetUserStatsForGame/v0002/?"](https://api.steampowered.com/ISteamUserStats/GetUserStatsForGame/v0002/?")
response = requests.get(url, params = request).json()
print(json.dumps(response))

zamieniłem pliki na stdin/stdout, bo jest prościej i zgodnie z UNIXową filozofią

[R.....y]

@Saly: @CancerLight: zamieniłem to na 4 funkcje, ale dalej w-------e komunikatów o błędach, nie brzmi jak dobry pomysł
https://pastebin.com/t0xUf4Qv

[R.....y]

@Saly: @CancerLight: zerknijcie teraz na to repo, czy jest waszym zdaniem lepiej

[CancerLight]

@RedveKoronny: lepiej, ale i tak sporo rzeczy do zmiany

[R.....y]

@CancerLight: co jest do zmiany, za wyjątkiem w-------a obsługi błędów?

[CancerLight]

@RedveKoronny: zastanów się co i kiedy powinno być w try-except, czy except może być puste, a może jednak zawierać się do pewnego jednego lub kilku wyjątków, co przyjmuje funkcja exit, czy get_data_from_api ma sens jak i tak musisz podać scieżkę do configa, a można byłoby to zrobić jako argument funkcji. Nie można użyć request.json(), tylko text parsować do jsona i jeszcze troche

[R.....y]

co przyjmuje funkcja exit

@CancerLight: exit code. Przyjęło się że cokolwiek co jest różne od 0 oznacza nieprawidłowe zakończenie programu. Całość wzięła się bodajże jeszcze z języka C, gdzie return był używany w głównej funkcji, żeby zakończyć ją w wypadku błędu (zwykle używano czegoś w stylu return -1, jako indykator błędu).
Komunikat o błędzie w formie stringa jest różny od 0, i użytkownik dostaje od razu komunikat że coś jest nie tak.
Mam