Attila Kovacs

No, the problem will be MapiLogon, don't use MapiLogon. Try this unit and give us feedback

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

But as a Library-Writer, this validation is a Plus, and not a "guard" for the rest of the code 😉

ok, you are right, I missed a lot from the beginning, my apologies

I would eventually, if I'm using them in the constructor. Eventually, as I'm not sure that an exception("I'm dumb") is better than an AV. If I'm not using them in the constructor, there is no reason to validate them. Also, it can be still trash because it's not nil.

he has no problems with memory management, he even made it clear in just a couple of replies above so I have no idea what you trying to prove here

Must be a very rare occasion where the parameter type itself does not cover the validity and the validity would not change with time, as far as I can think of. In this case of course a validation is not avoidable. However, I still think, that that is not the case behind the problem because it should be such rare, that he would not brought it up. I suspect over- and early-validation. At least, my advice was, not to do them if not neccessary.

So you are expecting and handling exceptions from the constructor but not expecting and not handling exceptions from any further method calls? Interesting.

It is. like if Parameter1 = null then raise...? What if that object is freed before you will use that in some of the methods? What is the advantage of this early-validation? It's just flow control in this case.

Can't see a damn question about memory management. Maybe I'm reading a different thread.

I was curious so I made this useless statistics over one of my projects WSL (always backup your files before playing with scripts on them) for i in `find . -name "*.pas" -type f`; do cat $i | sed -nr '/\bconstructor\b/I{:a;N;/end\;/I!ba;/begin/Ip}' | sed -e '1i\'$i'' | grep constructor; done | wc -l; 250 constructors (180 with parameter) for i in `find . -name "*.pas" -type f`; do cat $i | sed -nr '/\bconstructor\b/I{:a;N;/end\;/I!ba;/\sraise/Ip}' | sed -e '1i\'$i'' | grep constructor; done | wc -l; 11 explicit call for raise in a constructor (with parameter) if my scripts are right btw. Delphi sources 5137 / 306 (3937/244 with parameter)

@Dalija Prasnikar Hm, I really don't know what would I do on out of memory, never had to deal with that.

Actually I only handle exceptions where I have a plan B, otherwise I could only translate the messages to other languages.

what if time is a factor on that calls? are you swearing while you writing the code?;)

I'm always rising them there where it's not needed and mostly when I don't know. Sometimes not. You should have come up earlier with that.

Nothing. It's the class' design pattern. There could be an extra "Open" where the exception raises, makes no difference for me. But, following a design pattern makes life easier, so I'm trying to follow some rules, and yes, this can make things easier "better". It does not always work though.

If those methods are time critical you can do a lazy initialization or validate outside or even avoid OOP or whatever, but I would not validate in the constructor if I don't have to.

I can't think of everything right now but the LA := TRaiseOnMinus.Create( -2 ); //<== Raise seems to me a double act. Instantiate an object and doing something which raises an exception because of the parameter. In the constructor I mostly store the argument into a class field so It will cause an exception later, thus the constructor is not affected. Similar to Uwe's solution, but without initialize, just let it fail somewhere, but not in the constructor. Also, I suspect that you are using in this example exceptions to control the app. Don't do that if you can. Make the parameter type unsigned or let it fail somewhere if the parameter is negative but do not check it in the constructor and call raise. (If you can)

Events could be useful. OnProgress OnError OnQueryCancelled etc... Or fire up a brand new empty project and both projects should be able to use the same unit. But only that one. But, as far as I can see, this is not Ian's main goal this time. He is learning different things first.

As long as it's a windows application yes, use GetTickCount64. Whereas both will count the time the computer is in sleep or in hibernation. Not sure about TStopWatch.

just use the 2 TDateTime values, start/stop and use System.DateUtils.SecondsBetween(start, stop).

What do you mean with always?

He is right on this one.

since when is that?

I did not change anything since then. However I'm starting to encounter problems with Thunderbird too. Sometimes it just hangs and returns with unknown error. forsix.MapiMail.pas