Чому "посилання на об'єкт не встановлено на екземпляр об'єкта" не каже нам, який об'єкт?

Ми запускаємо систему, і ми іноді отримуємо відомий виняток NullReferenceExceptionіз повідомлення Object reference not set to an instance of an object.

Однак у методі, де у нас майже 20 об’єктів, журнал, який каже, що об’єкт є нульовим, насправді зовсім не корисний. Це як сказати вам, коли ви є агентом безпеки семінару, що людина серед 100 відвідувачів - терорист. Це вам взагалі не приносить користі. Вам слід отримати більше інформації, якщо ви хочете виявити, хто саме є загрозливою людиною.

Так само, якщо ми хочемо видалити помилку, нам потрібно знати, який об’єкт є нульовим.

Зараз щось одержило мою думку вже кілька місяців, і це:

Чому .NET не дає нам імені, або принаймні типу посилання на об'єкт, який є нульовим? . Ви не можете зрозуміти тип із відображення чи будь-якого іншого джерела?

Крім того, які найкращі практики зрозуміти, який об’єкт є нульовим? Чи слід завжди перевіряти зведеність об'єктів у цих контекстах вручну і записувати результат? Чи є кращий спосіб?

Оновлення: Виняток The system cannot find the file specifiedмає таку ж природу. Ви не можете знайти, який файл, поки ви не приєднаєтесь до процесу та не налагодите. Я думаю, ці види винятків можуть стати розумнішими. Чи не було б краще, якби .NET міг сказати нам c:\temp.txt doesn't exist.замість цього загального повідомлення? Як розробник я голосую так.

В NullReferenceExceptionосновному вам каже: ви робите неправильно. Нічого більше, нічого менше. Це не повноцінний інструмент налагодження, навпаки. У цьому випадку я б сказав, що ви робите неправильно і тому, що

• є NullReferenceException
• ви не завадили це тим, що ви знаєте, чому / де це сталося
• а також, можливо: метод, що вимагає 20 об’єктів, здається трохи недоцільним

Я великий любитель перевіряти все, перш ніж все почне йти не так, і надавати розробникові хорошу інформацію. Коротше кажучи: пишіть чеки за ArgumentNullExceptionдопомогою лайків і пишіть ім’я самостійно. Ось зразок:

void Method(string a, SomeObject b)
{
    if (a == null) throw ArgumentNullException("a");
    if (b == null) throw ArgumentNullException("b");

    // See how nice this is, and what peace of mind this provides? As long as
    // nothing modifies a or b you can use them here and be 100% sure they're not
    // null. Should they be when entering the method, at least you know which one
    // is null.
    var c = FetchSomeObject();
    if(c == null)
    {
        throw InvalidOperationException("Fetching B failed!!");
    }

    // etc.
}

Ви також можете ознайомитись із кодовими контрактами , у неї є химерність, але вона працює досить добре і заощаджує набір тексту.

Це дійсно повинно показати саме те, що ви намагаєтесь зателефонувати. Це як би сказати: "Є проблема. Вам потрібно її виправити. Я знаю, що це. Я не збираюся розповідати вам. Ви розібраєтесь" Більше, як іронічно, половина відповідей на цей стек переповнення.

То як корисно було б, наприклад, якби ти це отримав ...

Object reference (HttpContext.Current) not set to instance of an object

...? Потрібно зайти в код, переступити через нього і зрозуміти, що те, що ви намагаєтеся зателефонувати, - nullце добре, але чому б просто не дати нам трохи допомогти?

Я погоджуюся, що зазвичай корисно переглядати код, щоб дійти до відповіді (тому що ви, мабуть, дізнаєтесь більше), але часто багато часу та розчарування було б збережено, якби NullReferenceExceptionтекст був більше схожий на приклад вище.

Просто говорю.

Ваш журнал повинен містити стек стека - що зазвичай дає вам підказку щодо того, який рядок у методі має проблему. Можливо, вам потрібно буде зробити так, щоб ваша версія випуску включала символи PDB, щоб ви мали уявлення, на якому рядку вказана помилка.

Звичайно, це не допоможе вам у цьому випадку:

Foo.Bar.Baz.DoSomething()

Принцип " Tell not ask" може допомогти уникнути такого коду.

Щодо того, чому інформація не включена, я не впевнений - я підозрюю, що принаймні у налагоджувальній збірці, якщо вони справді цього захотіли, вони могли б це зрозуміти. Виконання аварійного дампа і відкриття в WinDBG може допомогти.

Виключення були створені як інструмент для передачі сигналу про надзвичайні не фатальні умови в ланцюзі викликів. Тобто вони не розроблені як інструмент налагодження.

Якщо виняток з нульовим покажчиком був інструментом налагодження, він би перервав виконання програми прямо на місці, що дозволить налагоджувачу підключитися, вказуючи його право на інкримінуючу лінію. Це дасть програмісту всю наявну інформацію про контекст. (Що в значній мірі те, що Segfault через нульовий доступ до вказівника робить у C, хоча і трохи грубо.)

Однак виняток з нульовим покажчиком розроблено як дійсне умова виконання, яке можна перекинути і потрапити в звичайний потік програми. Отже, міркування щодо ефективності потрібно враховувати. І будь-яке налаштування повідомлення про виключення вимагає створення рядкових об'єктів, об'єднаних та знищених під час виконання. Таким чином, статичне повідомлення, безперечно, швидше.

Я не кажу, що час виконання не міг бути запрограмований таким чином, що дав би ім'я звинувачувальної посилання. Це можна було б зробити. Це буде робити винятки навіть повільніше, ніж вони є. Якщо хтось піклується, таку функцію можна навіть зробити перемикаючою, щоб це не сповільнило виробничий код, але дозволило простіше налагодити; але чомусь ніхто, здається, недостатньо піклувався.

Я думаю, що хромулент вдарив нігтем по голові, однак є очевидний момент, що якщо ти отримуєш NullReferenceExceptionнеініціалізовану змінну (и). Аргумент того, що у вас близько 20 об'єктів, які передаються методу, не можна вважати пом'якшенням: як творець шматка коду, ви повинні нести відповідальність за його дії, що включає його відповідність решті бази коду, як а також правильне та правильне використання змінних тощо.

це обтяжливо, нудно і іноді тьмяно, але нагороди в кінці того варті: багато випадків, коли мені доводилося перебирати файли журналів вагою в кілька гігабайт, і вони майже завжди корисні. Однак перед тим, як дійти до цього етапу, налагоджувач може вам допомогти, і до цього етапу гарне планування заощадить багато болю (і я не маю на увазі повністю інженерний підхід до вирішення коду: прості ескізи та деякі замітки можуть і будуть бути краще, ніж нічого).

Щодо Object reference not set to an instance of an objectкоду не можна здогадатися за значеннями, які нам можуть сподобатися: це наша робота програмістів, і це просто означає, що ви пройшли неініціалізовану змінну в.

Навчіться користуватися налагоджувачем. Це саме та річ, для якої призначена. Встановіть точку перерви у відповідному методі та відійдіть.

Просто перегляньте свій код і точно подивіться, які значення мають всі ваші змінні в певних точках.

Редагувати: Чесно кажучи, я шокований тим, що ще ніхто не згадав про використання налагоджувача.

Якщо ви хочете перейти з відповіддю @ stijn і поставити нульові чеки у свій код, цей фрагмент коду повинен допомогти. Ось деяка інформація про фрагменти коду . Після цього налаштування просто введіть argnull, двічі натисніть на вкладку, а потім заповніть бланк.

<CodeSnippet Format="1.0.0">
  <Header>
    <Title>EnsureArgNotNull</Title>
    <Shortcut>argnull</Shortcut>
  </Header>
  <Snippet>
    <Declarations>
      <Literal>
        <ID>argument</ID>
        <ToolTip>The name of the argument that shouldn't be null</ToolTip>
        <Default>arg</Default>
      </Literal>
    </Declarations>
    <Code Language="CSharp">
      <![CDATA[if ($argument$ == null) throw new ArgumentNullException("$argument$");$end$]]>
    </Code>
  </Snippet>
</CodeSnippet>