Leaderboard

This sounds like a solution in search of a problem. As previously mentioned there are better options.

With EurekaLog, it is possible to capture and log EVERY exception before it is handled, so why bother with interfaces? We use inheritance, mostly to classify exceptions for a sub-domain. Exception - ParsingException - InvalidCSV - InvalidEmptyField try Parse; except on E:Excepetion do if E is ParsingException then LogSomethingInformative else raise. end;

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.

I don't see how it could help... if you want to extend any exception, incl 3rd party, they won't implement the interface. If you want to extend your own classes, why not inherit them from extended base class. Btw, you can wrap all exceptions thus extending ALL of them: (pseudocode) except on E: raise EExtended.Create(InnerException := E, AddInfo := ...) end Exception class even has the pointer to Inner exc already but I've never used it

I also find unit tests are a great way to start getting familiar with foreign code. Like libraries from 3rd parties or your own company. You're new to it, you don't really have a feeling for it yet. So before just straight out using the code in your real life application, why not start with a few unit tests so you know you can trust it for your use cases? Maybe you can even contribute the tests back.

Any problem can be expanded into something insurmountable if one so likes. But, if you apply the KISS and Pareto rules- you can at least start out with a less complicated scenario.

Would be nice to have a written transcript also. Many people (or at least one 🙂 ) prefers reading this kind of stuff instead watching youtube. Also no speakers connected at work to the computer.

Hello For the past few days I've been struggling trying to get the new Firebase integration of Delphi 11 (that was added in 10.4) for IOS to work, for Push Notification. Embarcadero really does a very poor job of documentation and sample code.. I'm impossible that they developed and never tested if this works... All the sample codes I found on the internet refer to the use of KastriFree library for FCM for IOS on Delphi, but supposedly, FCM for IOS support was added natively... and I would like to use the native implementation from Delphi instead of the third party library. I believe I have done all steps necessary (There are so many) Basically the iOS application is compiling with FCM successfully and it is starting as I can retrieve the phone Token, that is used to send the notification to.. but when I send notification on Firebase its never received by the phone, not even the test message from Firebase console... My firebase account is correctly linked to APNS using the APNS Key from apple Is there any tutorial on how to use Firebase Push Notification with iOS for Delphi 11 using the NATIVE implementation found on the new unit FMX.PushNotification.FCM.iOS ??

Yes, is was MS itself making that error. BTW, Windows 10 requires a reboot for the changes to get applied - and there is a similar entry under the WOW6432Node (both should match). Anyway, there were several things done to fix a GDI leak and significantly reduce the overall GDI handle usage in Delphi 11.

Can you show the Authentication tab, please?

@mvanrijnen Use https://downsub.com/ DownSub is a FREE web application that can download subtitles directly from Youtube, VIU, Viki, Vlive and more

OK, first test done successful! 🙂 Things are much clearer now! This video is for real beginners, very easy to follow: Thanks for the help everybody!

There are a number of uses for Unit Testing. Purists have their specific definitions, but it's a tool just like any other. You choose how to use it. Now, a hammer has some specific purposes like pounding in nails but you could use a hammer for quite a few more useful things. My advice is to start small - think of unit tests as simple stop/go signs for your code. Set a bare minimum functionality for each test. Then think about what possible abnormal inputs might occur and test for a few of those. Over time you'll end up with a large number of tests that add value to your operation. They will guard against you releasing some bugs that you might not have caught before. Once you start feeling comfortable with tests, then other uses arise. Like you start taking a little more risk - as you rely on your tests to keep you on the right path. Once you can take more risks, you could potentially make larger leaps forward in functionality. It's a self-feeding positive cycle. But in the beginning, add a single test and watch it fail. Your skill level went up +1. Now make that one test work and and then watch the test pass. Skill level +1. Write a little code and add another test... eventually write the test before the code is written (I don't do this often but when I have it has saved some time.)

What if the function has side effects?

who gives you the guarantee that the second call is returning the same value? <o>?

That doesn't make sense. You seldom attempt to write tests that exercise all combinations. That's the art of testing, finding a good set of test cases that are concise enough to verify, yet broad enough to provide comprehensive coverage.

And then proceeds to offer six bullet points of advice! I think that there is a lot more to unit testing than meets the eye. Unit testing is clearly about proving correctness of your code at the time you write it. It's also obviously about ensuring correctness of the code in the future in the face of modifications to code, refactoring etc. But I think what is often overlooked is that unit testing (and indeed other forms of testing) is very much about defining what your code does, pinning down the contract between the code and its clients (fancy word for the things that call the code under test). Well written tests can provide clear documentation of the code under test. This can be extremely useful when you need to remind yourself what a particular piece of code does. The implementation of the code may be hard to read and extensive. The documentation of the code may be sparse or non-existent. But a well-written test can provide the information you need to fully understand what you can expect a function or class to do. Furthermore, I routinely find that when I write tests, especially with this perspective of a test as documenting the contact, that I am unhappy with the original implementation and the contract that is implied. I will then refactor the code to achieve the contract that I want. This implies that testing early is good. Test driven development takes that view to the ultimate of writing tests before the code. But even if you aren't going that far, write tests as early as possible. Then when you discover that the contract isn't ideal, you can change it and reduce the impact of that change. Change to design always has smaller impact the earlier it is done in a design process.

OT: I was very pleased to see GitHub recently offering Colorblind Themes for people like me, who have difficulties to distinguish between red and green. (Actually I am able to distinguish both colors, but they look almost the same and I cannot say which one is green and which is red)

Form 652. That's a pretty extended hello world collection!