Jump to content

BestPractices: To raise, or not to raise ... an Exception in a class constructor

Recommended Posts

10 hours ago, Lars Fosdal said:

Sliding into off-topic, but I avoid parameters to constructors.

... and there we are again with Uwe's Initialize and my Conf_Setup_ scheme  ...

I like that approach too, because of the clear separation, but its hard to say where I should use that or better constructor parameters.

Maybe the experienced developer has always the right answer, but not me, I usually try and rework my classes many many times,

until I find a stable, acceptable final design.

Would be great to have some rules in what situations such separation makes sense, you gave already a good hint to that.


I like to use the Conf_Setup scheme in combination with the fluent interface, which makes class creation, or class builder, more nice and well readable.

    LMyObj := TMyObj.Create
    {} .Conf_Setup_Begin
    {} .Conf_Setup_Color(  clBlue      )
    {} .Conf_Setup_Events( EvOnChange  )
    {} .Conf_Setup_End
    {} ;


Most of the time I use class functions in those "Builders", which encapsulates class creation within the class itself.

Another step of separation creation and initialization within the "Builder".




Share this post

Link to post

What is the problem with conventional coding? Why the ascii art and why not use some properties and a normal try finally?



  • Like 1

Share this post

Link to post
3 hours ago, Attila Kovacs said:

What is the problem with conventional coding?

It's not "clever".

If real problems gets too hard to solve just invent some easy ones.

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