Object Pascal, Memory Safety, the US Whitehouse and future programming

[Thaddy]

C# is actually similar to Delphi in that you can call through the class definition:

Code: C  [Select][+][-]

1. using System;
2.  
3. public class TSomeClass
4. {
5.     public static int SomeMethod()
6.     {
7.         Random rnd = new Random();
8.         return rnd.Next(10);
9.     }
10. }
11.  
12. public class Program
13. {
14.     public static void Main()
15.     {
16.         // This works in C# - calling static method through null reference
17.         TSomeClass instance = null;
18.         Console.WriteLine(instance.SomeMethod());
19.        
20.         // But the preferred way is direct class call:
21.         Console.WriteLine(TSomeClass.SomeMethod());
22.     }
23. }

I needed some "help" for that, but it works.

[Warfley]

I suppose that hidden call to NewInstance assigns Self.
This case looks like a deliberate choice in the language implementation to allow Self be Nil.

Maybe instead of supposing you check?
If you did you'd see that the constructor is never called with nil as self:

Code: Pascal  [Select][+][-]

1. type
2.   TTest = class
3.   public
4.     class function newinstance: tobject; override;
5.     constructor Create;
6.   end;
7.  
8. class function TTest.newinstance: tobject;
9. begin
10.   Result:=nil;
11. end;
12.  
13. constructor TTest.Create;
14. begin
15.   WriteLn('Create: ', IntPtr(Self)); // Will not be executed
16. end;
17.  
18. begin
19.   TTest.Create;
20. end.  

So maybe you should stop base your arguments on guesses you make and instead start looking up if the things you claim are actually true or not. It's not like it's hard to verify, even if you don't have fpc locally installed, you can just put it into godbolt or any other online compiler and check it. I did so on my phone when I wrote the last answer. There is no excuse!

[AlexK]

There's a location in Free Pascal where Self can't be Nil so much - that there's no Self at all.

Code: Pascal  [Select][+][-]

1. class function TTest.newinstance: tobject;
2. begin
3.   // Allocation for this class reached a limit or computer says no.
4.   Result:=nil;
5. end;
6.  
7. constructor TTest.Create;
8. begin
9.   // Hidden NewInstance call inserted by compiler,
10.   // returns Nil immediately if NewInstance is Nil.
11.   // Self can be Nil anywhere else but not here.
12.   WriteLn('Create: ', IntPtr(Self)); // Will not be executed
13. end;

[Warfley]

While self cannot be nil in the constructor the following can happen:

Code: Pascal  [Select][+][-]

1. c := TTest.Create; // Allocation fails -> nil is returned
2. c.DoSomething; // Now nil is passed as self

This is theoretically possible, but in practice not really a problem, because, if the unit sysutils is used anywhere in the program, the Memory Manager will not return nil on error, but throw an exception. So in a "normal" control flow, you only get nil returned by the constructor if the project doesn't use the unit SysUtils. I'm sure there are a few people who use FPC without SysUtils, but the vast majority of users will have SysUtils used atleast in some unit or package. So a silent nil because the memory manager failed, does not really happen in practice.

So while I agree that the fact that self can be nil (or to be more precise, the fact that all pointers are nillable by default) can cause bugs, the thing you specifically are worried about simply does not happen, because thats just not an issue in any real world Pascal projects.

[440bx]

but one of the very real potential problems is that the exception handler that gets invoked isn't guaranteed to be the exception handler that is tailored to deal with a memory allocation failure while constructing the object/class.  The exception handler that is invoked may incorrectly "believe" that it dealt with the problem but unknowingly did so for a different cause.

Granted the above is not likely to happen if the exception handlers are kept _strictly_ local but, I've seen plenty of OOP code that handles exceptions across stack frames and, in that case, it's simply a free for all, anything can happen.

[Warfley]

To be honest most exceptions should be treated as "crash and burn". There are exceptions which can be handled sensibly, e.g. unexpected closing of a network connection. But when the memory allocator runs out of memory, at least on a modern system, this means something is going very wrong on the whole system, so there is no way how the program can continue normally.

[Thaddy]

Note that EOutOfMemory is pre-allocated (the only exception that is pre-allocated) to be able to at least inform.

What worries me more is that people are using far too much exception handling: many use it to direct code flow and that is wrong. Exceptions are, well, exceptions and thus unpredictable.

Code: Pascal  [Select][+][-]

1. {$ifdef fpc}{$mode objfpc}{$endif}
2. uses sysutils;
3.  
4. function AreYouAFool(const value:integer):boolean;
5. begin
6.   try
7.     if 1 div value <> 0 then result := true;
8.   except
9.     On E:EDivByZero do
10.       result := false;
11.   end;
12. end;
13.  
14. begin
15.   writeln(AreYouAFool(10));
16. end.

Don't laugh, that's how many misuse exception.

[AlexK]

Exceptions are, well, exceptions and thus unpredictable.

Exception are used for non-local exit because something is predicted or expected up the call stack.
Try/catch blocks may reside inside a loop that retries deep call stacks in modified context to find a solution.

Languages like Dart can throw any type as exception, no need to wrap it in Exception subclass. Any string, number, instance.

[Thaddy]

Then they should call it protection instead of exception.

[Zoran]

Languages like Dart can throw any type as exception, no need to wrap it in Exception subclass. Any string, number, instance.

C++ can throw any type, even primitive such as int. It is however strongly recommended to throw only descendants of std::exception class.

In Free Pascal, you can "raise" any class, it doesn't have to descend from SysUtils.Exception. It has to be a class type, though. You can't raise a primitive.
From the Reference manual (17.1 The raise statement):

Remark Although the Exception class is used as the base class for exceptions throughout the code, this is just an unwritten agreement: the class can be of any type, and need not be a descendent of the Exception class.

Of course, most code depends on the unwritten agreement that an exception class descends from Exception.

[AlexK]

Languages like Dart can throw any type as exception, no need to wrap it in Exception subclass. Any string, number, instance.

In Free Pascal, you can "raise" any class, it doesn't have to descend from SysUtils.Exception. It has to be a class type, though. You can't raise a primitive.

Indeed.
In Dart any value can be raised as an exception because all types descend from root Object, even primitive types.
In FPC primitive types are separate and can be grouped by a Variant type.

[AlexK]

But the MR sits around since then

After migration to GIT in 2021, FPC seems to slowed down adoption of features or development became more like in LuaJIT where main maintainer recons that minor versions do not matter with modern VCS.

[PascalDragon]

FPC seems to slowed down adoption of features or development became more like in LuaJIT where main maintainer recons that minor versions do not matter with modern VCS.

Adoption of features has nothing to do with the migration to Git. Though only in so far that we now get more feature requests than before and we need to deal with those, but we're not simply adding everything and the kitchen sink.
That there is no new minor release yet is simply due to the changes in the release management that aren't yet fully worked out. So that is definitely more due to the migration to Git.