Jump to content
David Schwartz

handling predicate conditions

Recommended Posts

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) 

Share this post


Link to post
28 minutes ago, Stefan Glienke said:

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

Erm, yes. 

Share this post


Link to post
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. 

Share this post


Link to post
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.

Share this post


Link to post

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. 

Share this post


Link to post
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 :)

Share this post


Link to post
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 by Georgge Bakh

Share this post


Link to post
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 by David Schwartz

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×