handling predicate conditions

[Dalija Prasnikar 1396]

13 hours ago, David Heffernan said:

Why even bother writing those checks? An exception will be raised as soon as you attempt to use the nil instances. 

In addition to what @Stefan Glienke said, on Delphi LLVM based compilers exception triggered by accessing nil reference will wreak havoc because it will not be caught by current method exception handlers (and finally blocks will not be executed either) 

[David Heffernan 2345]

28 minutes ago, Stefan Glienke said:

everyone knows what an access violation at 0x0071f2a7: read of address 0x000000f7 means, right?

Erm, yes. 

[David Heffernan 2345]

18 minutes ago, Dalija Prasnikar said:

In addition to what @Stefan Glienke said, on Delphi LLVM based compilers exception triggered by accessing nil reference will wreak havoc because it will not be caught by current method exception handlers (and finally blocks will not be executed either) 

Not something I've ever experienced being a Windows only delphi dev. 

[PeterBelow 238]

14 hours ago, David Heffernan said:

Why even bother writing those checks? An exception will be raised as soon as you attempt to use the nil instances. 

Yes, but the error you get then will not immediately indicate what the problem is. The way I do it its clear that the problem is a contract violation, and one can write unit tests that check whether the method correctly detects a contract violation.

[David Heffernan 2345]

The downside of adding checks is that the code bloat is huge. Imagine a function that accepts three args and just forwards them on to another method. You then have three checks against nil, and a single line to forward the call. That burden adds up. Having this checked statically, or even at runtime like range checking would be a boon. 

 

Of course, none of that helps with the much more invidious error of passing a reference to an already destroyed object. 

[Stefan Glienke 2002]

10 minutes ago, David Heffernan said:

The downside of adding checks is that the code bloat is huge. Imagine a function that accepts three args and just forwards them on to another method. You then have three checks against nil, and a single line to forward the call. That burden adds up. Having this checked statically, or even at runtime like range checking would be a boon. 

 

Of course, none of that helps with the much more invidious error of passing a reference to an already destroyed object. 

Use Rust if you want that :)

[Georgge Bakh 29]

20 hours ago, David Schwartz said:

So how do you bail out of the procedure if a check fails? Does this throw an exception? Or is another test needed?

When a check fails the result of the chain call is an object of a special class (TFailedValidator?). Which let say hasFailed() method returns True. 🙂

Depending on actual code of Validator and TFailedValidator you can check what happened and decide what to do.

On 8/6/2019 at 11:24 PM, David Heffernan said:

Why even bother writing those checks? An exception will be raised as soon as you attempt to use the nil instances. 

In addition to other answers, explicit checks can act as contracts which can be easily read and also used by IDE and/or external static code analysis tools.

Edited August 7, 2019 by Georgge Bakh

[David Schwartz 426]

On 8/6/2019 at 11:17 PM, Schokohase said:

We can only be theoretically/abstract because you asked a theoretically/abstract question: 

 

I was looking for examples.

Edited August 8, 2019 by David Schwartz