4

The null pointer dereference usually results to runtime error and program crashes immediately. Why not to make these cases exceptional, throw exception and allow programmer to handle it runtime and keep program running?

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
Igor
  • 124
  • 10

2 Answers2

11

Because they would require an extraordinary level of runtime support, mandating checks on every single pointer access and vastly slowing down everybody's C++ programs whether they wanted this heavy-handed behaviour or not.

You are free to create a wrapper class that validates nullity on every access, and use that class when (and only when) you feel you need it. However, this would be considered a design smell, as you should never need such a device.

Instead, use proper memory management techniques that leave you without any null pointers whatsoever; the end of life of your pointees and your pointers should be the same.

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
  • Nicely written! – Brian Sep 05 '16 at 19:47
  • @JohannGerell: [It most certainly is.](http://stackoverflow.com/q/6793262/560648) – Lightness Races in Orbit Sep 05 '16 at 20:06
  • Side note: checking the pointer isn't actually that expensive. Handling it is. Checking the pointer is as easy as just referencing the the pointer and making the first 64k of memory a guard page. That triggers an access violation the kernel handles (this is actually how the .NET CLR does it). Because this requires a fault however this is expensive when it actually happens. – Mgetz Sep 06 '16 at 11:30
  • @Mgetz: OP is asking about firing a C++ exception. So, attaching a "watch" and a condition to every single access of every single pointer would indeed be prohibitively expensive in many deployments. – Lightness Races in Orbit Sep 06 '16 at 11:31
  • @LightnessRacesinOrbit [not as expensive as you'd think](https://blogs.msdn.microsoft.com/oldnewthing/20070816-00/?p=25553) – Mgetz Sep 06 '16 at 11:31
  • @Mgetz: That does not trigger a C++ exception. It's a much lower-level mechanism that implements how it works now, not how the OP wants it to work. – Lightness Races in Orbit Sep 06 '16 at 11:32
  • No, and I'm not disputing that... I'm just saying there are ways – Mgetz Sep 06 '16 at 11:33
  • You keep linking to an irrelevant article about an irrelevant technique. That does not throw a C++ exception, is for code that is already managed, and is for C#.... – Lightness Races in Orbit Sep 06 '16 at 11:33
1

Why null pointer dereference is not an exception?

Because it doesn't make sense in a language like C++ with a lot of other safety breaches. Why would you require that dereferencing a null pointer generates an exception but not care about dereferencing dangling pointers and out-of-bounds access?

Why not to make these cases exceptional, throw exception and allow programmer to handle it runtime and keep program running?

Dereferencing a null pointer is nothing else than a programming error (a bug). Of course it would be nice if all bugs were caught by the compiler or the runtime, so that programmers wouldn't spend millions of man-hours investigating them. That's a valid reason for desiring a special compilation mode where all such invalid operations would trap.

However, in a tested/debugged program invalid operations should not occur. I can hardly imagine reasonable handling of an exception thrown as a result of a bug that would keep the program running and functioning up to the spec. If you know precisely where a null-pointer exception may originate from, then you can definitely prevent it in the first place. If it suddenly explodes from where you didn't expect it, then I bet your program will start misbehaving even if it's perfectly exception safe. I agree, that damage from such faults occurring in production environments will be minimized, however you will still have to program with the intention of preventing those exceptions from firing rather than letting them fire and then dealing with the consequences.

Leon
  • 31,443
  • 4
  • 72
  • 97
  • sorry to necro but "Why would you require that dereferencing a null pointer generates an exception but not care about dereferencing dangling pointers and out-of-bounds access?" Checking if a pointer dereference is null amounts to a zero check, which is a single instruction followed by some conditional branching. Compare that to trying to decide if a pointer is "dangling" or not, or "out-of-bounds access" which requires overhead storage of allocation data and lookups on that data. If you can trivially stop a program from crashing on a nullptr, why wouldn't you? – Dante Jan 28 '20 at 22:19
  • @Dante *If you can trivially stop a program from crashing on a nullptr, why wouldn't you?* That is covered in the second part of my answer – Leon Jan 29 '20 at 07:11