Jump to content

Wagner Landgraf

Members
  • Content Count

    92
  • Joined

  • Last visited

Posts posted by Wagner Landgraf


  1. 1 minute ago, David Heffernan said:

    I don't really see the value of this, if the input is contracted to be assigned. That makes it a programming error, your tests will AV and you will fix it. No need to clutter the code with if not Assigned tests. 

    Fair enough, it was more an example to show that relying on the parameter type is sometimes not enough. But as a library writer I don't think it's bad to give a better error message to the user of my classes (whose code I have no control of) telling him what he did wrong, instead of raising a cryptic AV and waiting him to realize what he did wrong or even blame the framework itself.

    • Like 1

  2. 1 minute ago, Attila Kovacs said:

    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.

     

    If the interface is required for your whole class to properly work, why you wouldn't want to check it in the constructor? Why allowing a instance to be created in an "invalid" state? You would have to check if the interface is nil everywhere in your code and for no use, since your class won't work without it.


  3. 12 minutes ago, Attila Kovacs said:

    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.

    A very common case is when you inject objects and interfaces in the constructor. At the very least you would want to check if they are not nil.

    • Like 3

  4. 1 hour ago, Attila Kovacs said:

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

    I see lots of discussions about how to properly structure try..finally statements and how it behaves depending if a constructor raises an exception or not; if the object should be created inside or outside the try..finally, if the destructor should have a try..finally inside it, etc.

    Maybe indeed it's a different one. This is the one I'm reading: https://en.delphipraxis.net/topic/6149-bestpractices-to-raise-or-not-to-raise-an-exception-in-a-class-constructor

     


  5. 30 minutes ago, Anders Melander said:

    Yes, it probably could be done, but should it?

    It's not a bad idea, but without low level compiler support (on E: IMyError do ... ) I wouldn't do it. Personally I want my error handling to be as simple and robust as possible so it doesn't potentially make a bad situation worse.

    It's an interesting approach when you have a centralize exception handler/processor mechanism - like logging systems, serializers, servers, etc.. It's a way to add metadata to the exception without having to be strict to a specific class hierarchy.


  6. 3 minutes ago, Wil van Antwerpen said:

    The problem is that Microsoft does not provide licenses for that and so far there are no indications that they ever will. Windows on Arm only works with OEM hardware suppliers and apple isn't one of them.

    That was true for Windows 10, are you sure it will be the same for Windows 11? I believe ARM in Windows 11 will be a 1st class citizen like Intel.


  7. 1 hour ago, Fr0sT.Brutal said:

    imagine 10 copies of JVCL...

    If I'm not wrong, @Vincent Parrett's package manager puts the packages in a global cache. So if you have multiple projects using the same version of JVCL, only one copy will be in your storage. If a couple of projects use an older version, then you will have two copies of JVCL. So it's the ideal scenario. I guess that's how it works, but he can confirm it. 


  8. I think the "problem" with Package Manager is that is has to be widely adopted by the community to be very useful. Because the key is that relevant libraries and 3rd parties are available in the package manager. "Unfortunately" Embarcadero is pushing GetIt so it's unlikely we will have a different one being widely adopted, I guess.

    • Like 2

  9. 1 hour ago, Stefan Glienke said:

    The question is this: do you want to get a wide adoption rate of something you've built or do you want to get two and a half coffees paid.

     

    As for how the console is done: Visual Studio Code simply communicates via stdin/stdout/stderr - see https://vscode.readthedocs.io/en/latest/editor/integrated-terminal/ 

    Or if you want to find a way to do constant updates and improvements or leave it abandoned.

×