[Из песочницы] Как generic-и нас спасают от упаковки08.07.2017 12:32

Комментарии (8)

  • 7 июля 2017 в 22:26

    0

    ↑

    ↓

    Хочется отметить вопрос терминологии. Value types переводятся как «значимые», а не вещественные. Этот вопрос принципиален, так как, например, тип Int32 (Value type, как вы понимаете) является целочисленным, не вещественным.

    • 7 июля 2017 в 23:13

      +1

      ↑

      ↓

      Спасибо, поправил.

  • 7 июля 2017 в 23:03

    0

    ↑

    ↓

    Опыт работы с приложением для автоматизации ВУЗа показывает, что такие исключения (ArgumentNullException) характерны для недописанного софта… Ведь логика (если нет бананов, купи яблок) проще, чем (бананов нет, паника!)(если паника из-за отсутствия бананов, купи яблок).

    • 7 июля 2017 в 23:08 (комментарий был изменён)

      0

      ↑

      ↓

      Проектируя библиотеку, вы например не сможете избежать неправильного использования функции, и кто-нибудь да подаст аргумент null. Когда бизнес-логика не позволяет продолжить поток выполнения, лучше выбросить исключение, ну и задокументировать в каком случае оно будет выброшено.

    • 8 июля 2017 в 04:44

      0

      ↑

      ↓

      А еще некоторые убежденно доказывают, что кидаться исключениями — моветон, т.к. исключительная ситуация по их мнению, это когда сервер отвалился, в остальных случаях можно просто вернуть null и написать if. Это не про Java, но тем не менее.

      • 8 июля 2017 в 11:11

        0

        ↑

        ↓

        Всегда кидать исключения и никогда не использовать исключения — это две крайности. Но если откуда-то появился пустой указатель — причина в источнике этого указателя, и ситуация должна обрабатываться после появления этого указателя, а не во вложенной функции или где-то еще, иначе логика размазывается, и поддерживать её сложнее (ведь последующий код кроме ненулевого указателя теперь должен учитывать и пустой).

        Вообще я пытаюсь сказать, что мне больше нравится так

        function getApple() {
    return null;
}

function bar(apple) {
    ...
}

function foo() {
    var apple = getApple();

    if (!apple) {
        throw new Error('apple is empty!');
    }

    bar(apple);
    ...
}

        чем так
        function getApple() {
    return null;
}

function bar(apple) {
    if (!apple) {
        throw new Error('apple is empty!');
    }

    ...
}

function foo() {
    var apple = getApple();

    bar(apple);
    ...
}

        Но, может, я заблуждаюсь, т. к. разрабатывать большие программы мне не доводилось.

    • 8 июля 2017 в 04:56

      +1

      ↑

      ↓

      Т.е. по-вашему, по мере дописывания софта, эти проверки убираются? И, вообще, что такое дописанный софт? Примерчик бы.

      Из моего опыта, проверка аргументов появляется либо сразу в методе публичного API, либо после того, как кто-то словил NullReferenceException.

      • 8 июля 2017 в 11:53

        0

        ↑

        ↓

        Нужно различать проверку входных данных и проверку аргументов функции/метода.
        Проверка входных данных должна быть сразу же (если, конечно, это не прототип), и о неправильном вводе пользователь должен получать вменяемое сообщение. А внутренние методы, по хорошему, не должны вызываться с пустыми (= NULL) аргументами (хотя здесь много исключений).
        после того, как кто-то словил NullReferenceException

        Вот это и есть — недописанный софт. Приходится писать руководству выше, они пишут разработчикам, разработчики исправляют, высылают (!) новую версию программы, ну, а пользователь теряет день-два-неделю.

© Habrahabr.ru