Здравствуйте, Аноним, Вы писали:
А>в вышеприведенном куске кода не нравится то, что мы ловим исключение CSyntaxError, и re-throw-им его, а выше, в самой main() еще раз ловим его. налицо нерациональность.
перевыбрасывание исключение делается через throw без параметра, а не так, как ты написал. Поскольку ты ловишь по ссылку, то ты можешь поймать исключение производного класса, и при твоем способе "перевыброса" произойдет срезка (т.е. создастся _новый_ объект класса CSyntaxError) вместо настоящего перевыброса оригинального исключения.
А>логика такова, что при выбрасывание исключения в методе CParser::parser() уже является достаточным для завершения проги. но как-то писать в этом методе здесь exit(-1); рука не поднимается.
Завершение проги — забота проги, а не парсера.
Разделение ответственности (и ограничение ответственности одного класса, a.k.a single responsibility principle) — это правильный путь.
Парсер не должен заниматься остановом программы, он должен просто рапортовать об ошибках парсинга.
Так что все нормально.
Тем более что позже тебе понадобиться грохать программу и по другим исключениям, кроме парсинга (например, потому что не найден файл с данными или там сокет не создался), и твой catch преобразуется.
А>у кого-нибудь есть идеи по поводу улучшения этого подхода? просто нужно мозгам моим перестроиться на нужную стезю, а сам не могу непредвзято посмотреть на это все. А>жду подсказки, спасибо.
Идея одна — когда дизайнишь класс, думай о том, как он будет использоваться в другой проге или в другой ситуации.
Даже если этот класс будет использоваться только в этой одной программе.
Этим ты сильно упростишь себе и разработку, и дальнейшую поддержку.
Гораздо проще жить, зная, что парсер только парсит, чем помнить, что парсер и парсит, и иногда грохает программу, и иногда на машинке крестиком...
