Чистый код: блоки try/catch. Стоит ли так делать? Читаю Рики Роберта Мартина - "Чистый Код". И до сих пор думаю об одном его совете, с которым мне тяжело согласиться. Мартин советует изолировать блоки try/catch, т.е. всю область, что находится в блоке try выделить в ОДИН отдельный метод. Например, вот такой довольно лаконичный и легко читаемый метод:public void delete(Page page)
{
try {
deletePage(page);
registry.deleteReference(page.name);
configKeys.deleteKey(page.name.makeKey());
} catch (Exception e) {
logger.log(e.getMessage());
}
}
Мартин предлагает преобразовать в два метода:public void delete(Page page)
{
try {
deletePageAndAllReferences(page);
} catch (Exception e) {
logger.log(e.getMessage());
}
}
private void deletePageAndAllReferences(Page page)
{
deletePage(page);
registry.deleteReference(page.name);
configKeys.deleteKey(page.name.makeKey());
}
Мартин говорит, что таким образом мы отделяем бизнес-логику от обработки ошибок.
Но, мне кажется, это избыточно. Да, разумеется, если у нас в try {} сложная логика то ее следует декомпозировать, но если у нас в try {} несколько понятных вызовов методов, то разве нужно выделять их в один метод? Тем более, становится сложно придумать РАЗНЫЕ названия для двух методов, которые делают по сути одно и то же. При этом, сам же Мартин очень большой акцент делает на хорошем и не запутывающем именовании методов.
Как считаете, стоит ли так делать? И следуете ли вы сами такому примеру?
Чистый код: блоки try/catch. Стоит ли так делать? Читаю Рики Роберта Мартина - "Чистый Код". И до сих пор думаю об одном его совете, с которым мне тяжело согласиться. Мартин советует изолировать блоки try/catch, т.е. всю область, что находится в блоке try выделить в ОДИН отдельный метод. Например, вот такой довольно лаконичный и легко читаемый метод:public void delete(Page page)
{
try {
deletePage(page);
registry.deleteReference(page.name);
configKeys.deleteKey(page.name.makeKey());
} catch (Exception e) {
logger.log(e.getMessage());
}
}
Мартин предлагает преобразовать в два метода:public void delete(Page page)
{
try {
deletePageAndAllReferences(page);
} catch (Exception e) {
logger.log(e.getMessage());
}
}
private void deletePageAndAllReferences(Page page)
{
deletePage(page);
registry.deleteReference(page.name);
configKeys.deleteKey(page.name.makeKey());
}
Мартин говорит, что таким образом мы отделяем бизнес-логику от обработки ошибок.
Но, мне кажется, это избыточно. Да, разумеется, если у нас в try {} сложная логика то ее следует декомпозировать, но если у нас в try {} несколько понятных вызовов методов, то разве нужно выделять их в один метод? Тем более, становится сложно придумать РАЗНЫЕ названия для двух методов, которые делают по сути одно и то же. При этом, сам же Мартин очень большой акцент делает на хорошем и не запутывающем именовании методов.
Как считаете, стоит ли так делать? И следуете ли вы сами такому примеру?
{
try {
deletePage(page);
registry.deleteReference(page.name);
configKeys.deleteKey(page.name.makeKey());
} catch (Exception e) {
logger.log(e.getMessage());
}
}
Мартин предлагает преобразовать в два метода:public void delete(Page page)
{
try {
deletePageAndAllReferences(page);
} catch (Exception e) {
logger.log(e.getMessage());
}
}
private void deletePageAndAllReferences(Page page)
{
deletePage(page);
registry.deleteReference(page.name);
configKeys.deleteKey(page.name.makeKey());
}
Мартин говорит, что таким образом мы отделяем бизнес-логику от обработки ошибок.
Но, мне кажется, это избыточно. Да, разумеется, если у нас в try {} сложная логика то ее следует декомпозировать, но если у нас в try {} несколько понятных вызовов методов, то разве нужно выделять их в один метод? Тем более, становится сложно придумать РАЗНЫЕ названия для двух методов, которые делают по сути одно и то же. При этом, сам же Мартин очень большой акцент делает на хорошем и не запутывающем именовании методов.
Как считаете, стоит ли так делать? И следуете ли вы сами такому примеру?
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
Каждый разработчик имеет свое мнение на этот счет, и нет однозначного ответа на вопрос, стоит ли изолировать блоки try/catch в отдельные методы. Основное преимущество такого подхода заключается в том, что это улучшает читаемость кода и обеспечивает более явное разделение бизнес-логики и логики обработки исключений. Это может быть особенно полезно в случае сложной логики или если вы хотите обработать ошибку по-разному в зависимости от контекста.
Однако, как вы правильно отметили, в случае простых блоков try/catch создание дополнительного метода может показаться избыточным. Это может усложнить код и сделать его менее читаемым, особенно если требуется придумать разные названия для двух методов, которые по сути делают одно и то же.
Таким образом, решение о том, стоит ли изолировать блоки try/catch в отдельные методы, должно зависеть от конкретного контекста и сложности логики. В случае простых блоков try/catch, возможно, имеет смысл оставить их внутри основного метода для улучшения читаемости и уменьшения избыточного кода. Однако, в случае сложной логики или необходимости обработки ошибок по-разному, изоляция блока try/catch в отдельный метод может быть полезным решением.