Unexpected deprecated warnings at end of constructors

[Thaddy]

Everyone that needs to call FreeAndNil is not a proper programmer.
It means that your code is not safe and you have to review your code to avoid such nonsense.
It is very rare that FreeAndNil adds anything useful to code, very rare.
But it seems endemic on this forum...

[Чебурашка]

Everyone that needs to call FreeAndNil is not a proper programmer.

It's 25 years I am not a proper programmer.
And it will be 25 years more I won't be, if God wants.

[Чебурашка]

Everyone that needs to call FreeAndNil is not a proper programmer.
It means that your code is not safe and you have to review your code to avoid such nonsense.
It is very rare that FreeAndNil adds anything useful to code, very rare.
But it seems endemic on this forum...

The equation

<you use FreeAndNil = your code isn't safe>

is undemonstrated so is just an opinion.

[WooBean]

Everyone that needs to call FreeAndNil is not a proper programmer.
It means that your code is not safe and you have to review your code to avoid such nonsense.
It is very rare that FreeAndNil adds anything useful to code, very rare.
But it seems endemic on this forum...

Lazarus is full of "FreeAndNil"s, especially at various "Clear" methods implementations.
Let us say that at least not every Lazarus co-author is not a proper programmer.

[Bart]

This is getting off-topic (the discussion about FreeAndNil).

This post is about he compiler misplacing the warning (e.g. the x,y coördinates in the message are wrong).
To me that sounds like a bug and it may be worth while posting it in the bugtracker with a small demo.

Bart

[alpine]

This post is about he compiler misplacing the warning (e.g. the x,y coördinates in the message are wrong).
To me that sounds like a bug and it may be worth while posting it in the bugtracker with a small demo.

Actually is about compiler generating an extra warning at the place the OP doesn't expect it, i.e. doesn't call Destroy explicitly, but the compiler puts an implicit call there in the case of unhandled exception.   

[Чебурашка]

I am very sorry that some replies included this things related to the usage of Destroy/Free/FreeAndNil, that have nothing to do with my original question. In my opinion, I find that it has been already told many times about this, and the ones who continue to point it out are somehow wasting other's time.

If I knew I'd write the software example direclty in the "recommended way" in order to avoid them to write the usual useless replies.

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

1.   x := TMyClass.Create();
2.   try
3.     // ...
4.   finally
5.     {$IFDEF Thaddy}x.Free();{$ELSE}FreeAndNil(x);{$ENDIF}
6.   end;
7.  

[Чебурашка]

This post is about he compiler misplacing the warning (e.g. the x,y coördinates in the message are wrong).
To me that sounds like a bug and it may be worth while posting it in the bugtracker with a small demo.

Actually is about compiler generating an extra warning at the place the OP doesn't expect it, i.e. doesn't call Destroy explicitly, but the compiler puts an implicit call there in the case of unhandled exception.

The point could be summarized/generalized as: is it right that an implicit call (made by compiler) to a deprecated method generates a warning like explicit calls (made by programmer) do?

[alpine]

@Чебурашка
I'm curious, why would you declare the destructor as deprecated?

[Чебурашка]

@Чебурашка
I'm curious, why would you declare the destructor as deprecated?

Because I need the compiler to tell me all places where objects are used/constructed/destructed, because I need move this class' usage within a wrapper class and I want the compiler to help me to do the transition process and prevent (actually warn) from future access to the deprecated. The final goal is that this class can be manually constructed destructed in special cases (and in that case I will manually silence tha warning), but normal usage has to be mediated by a wrapper. Just to add mode details is a set of objects related to database connections, transactions, queries and so on.

Databases are the Viet-nam of programming.
Except for proper programmers.

[alpine]

@Чебурашка
I'm curious, why would you declare the destructor as deprecated?

Because I need the compiler to tell me all places where objects are used/constructed/destructed, because I need move this class' usage within a wrapper class and I want the compiler to help me to do the transition process and prevent (actually warn) from future access to the deprecated. The final goal is that this class can be manually constructed destructed in special cases (and in that case I will manually silence tha warning), but normal usage has to be mediated by a wrapper. Just to add mode details is a set of objects related to database connections, transactions, queries and so on.

Databases are the Viet-nam of programming.
Except for proper programmers.

I see. But usually Destroy never gets called directly and deprecated is used for old/bad methods, etc. IMO that warning is quite reasonable.

[Bart]

Reported as issue #40434.

Bart