- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
class FileCheckError(Exception):
def __init__(self, check, file):
self.check = check
self.file = file
self.exceptions = ['не является файлом',
'не является .wav файлом',
'не находится в списке требуемых сэмплов',]
def __str__(self):
return f'{self.file} {self.exceptions[self.check]}'
def validate_pack(pack) -> list:
"""
Checks for invalid files in a pack folder
Makes a list of invalid files if found any or
makes a list of accepted samples
"""
accepted_samples = []
found_errors = []
for sample in listdir(pack):
checks = [isfile(join(pack, sample)),
fnmatch(sample, '*.wav'),
Path(pack / sample).stem in required_samples, ]
try:
for check in range(len(checks)):
if not checks[check]:
raise FileCheckError(check=check, file=sample)
except FileCheckError as E:
found_errors.append(str(E))
continue
accepted_samples.append(sample)
if len(found_errors) != 0:
return found_errors
else:
return accepted_samples
result = validate_pack(Path('drumpacks/rock'))
print(result, sep='\n')
все грязные извраты от наследуемости.
Ну и если хочется писать говно, то хоть немного думай: exceptions спокойно можно сделать аттрибутом класса, а не пихать в каждый экземпляр.
Ну и if len(found_errors) != 0: → if found_errors:
* стат типизация то частично есть, то нет (в 2022 надо сделать ее поностью и везде)
* ошибки внутри через исключения, снаружи черех хуй пойми что
Нужно либо возвращать два значения (ошибки,ответы) как в го, либо всегда кидать исключение в случае ошибки, либо возвращать какой-нить result и потом его паттерн матчить в ошибку или удачу (но в питухоне так не делают)
Вообще, во всех мейнстримных языках ошибки обрабатываются неправильно
- last_error это int. Если это не int или ты случайно его удалил, готовься к крашу, ни одна из уже имеющихся функций в кодовой базе этого не ожидает.
- У каждой функции свой список кодов ошибок. После вызова одной функции last_error 5 означает совсем не то, что после другой.
- после вызова функции проверь last_error. Если оно не 0, игнорируй возвращаемое значение, что там лежит — не ведомо никому (обычно None или частично обработаный входной контейнер).
- Обработал last_error? Установи его обратно в 0. Иначе некоторые фуккции начнут возвращать странные ошибки или вообще падать (так как везде last_error сбрасывается после вызова функции, то если функция его не трогала, прошлая ошибка будет принята за текущую. Или какая-то функция попытается посмотреть, что это за ошибка №5 для функции с тремя видами ошибок).
- Вылетело исключение? Погоди радоваться, last_error придётся скорее всего проверить. Есть 4 варианта:
0) Ни last_error, ни исключение (которое Exception, никаких подклассов) ничего не значат, причём и в том и в другом может что-то быть написано. Всё, что ты знаешь — что-то пошло не так.
1) Игнорируй last_error, всё ценное хранится в исключении. Но last_error и в этом и в прошлом случае обнули — просто потому что он может быть поставлен в какое-то странное значение.
2) Игнорируй исключение, тебе нужен last_error. Помнишь, что его смысл меняется для каждой функции? Удачи с угадыванием какая функция кинула исключение, если у тебя try блок не одну функцию покрывает.
3) Оба важны, в last_error собственно ошибка, в исключении хранится какая-то допинформация (вроде имени файла или ещё что)
- В коде иногда используются асинхронные вызовы. Удачи, блядь.