David Heffernan

Erm, yes.

Every function you write that accepts a reference type, you check that it is assigned on entry to the function?

Examples aren't much use without understanding the rationale behind them. If exceptions are a PITA you must be doing something wrong. It's error handling without exceptions that is a PITA.

Reasonable at certain interfaces between modules, but not in every single function.

Why even bother writing those checks? An exception will be raised as soon as you attempt to use the nil instances.

I guess it depends on what motivates you. Do you want to optimise for the quality of your program's UX, or is it more important to you that you can create the UX as quickly as possible, irrespective of how well it works?

It still says exceptions to me. But you say that you don't want to use exceptions. Can you explain why you don't want to use exceptions?

This isn't using exceptions for control flow. It's using exceptions to deal with invalid parameters. If you don't use exceptions, and you show a message dialog to the user then what is code going to do next? How are you going to avoid following the normal execution path. You can exit this function. But what about the caller? And its caller? And its caller? And what about when you run your code through your program's API rather than interactively. Pretty debilitating to show a dialog to an API user.

Best is to use exceptions of course

What is more important to you? A solution that works, and 1mb extra exe file size, or no solution and 1mb smaller exe size?

Depends on your program's requirements and memory usage patterns. What are you trying to achieve with a change of memory manager?

Attributes are fragile by design. The compiler cannot verify that you supplied the appropriate attributes to make your program work correctly. For example, at the outset of this thread you are faced with an attempt to pass a typed constant to an attribute constructor and the compiler objects. Well, remove the entire attribute declaration and now your program will compile.

VCL styles anybody?

Really? I think that new features are poorly documented, but long standing language features are actually well documented.

Except that it doesn't work. Doesn't handle errors at all. Also, it's fine that you don't want to disturb your code. But if you are going to offer up code as an example, it should be exemplary.

Why do you think ShellExecute throws exceptions? It doesn't. If you want proper error handling use ShellExecuteEx, and check the return value. Even ShellExecuteEx would be wrong here though. Use CreateProcess. As for services, why use cmd.exe to run net.exe? Why not run it directly? Of course, the API is the right way to start a service.

Why put up with it. Progressively strip code out until the warning disappears. That will lead you to the duplication.

I don't buy that argument. Your program needs to be able to adapt to changes in screen resolution. When restoring the form layout you must deal with the screen resolution having changed, roaming or not. User can change resolution, font scaling, changes attached monitors, etc. Having said that, I am sure that an argument could be constructed to justify not having such settings roam. In fact, using that part of the user profile that resides on the filesystem allows you to choose between roaming and local on a per setting basis. That's certainly an advantage over HKCU.

I understood that HKCU did roam

I can't make sense of this. You are implying that HKCU always roams? And that roaming is not appropriate for such settings?

%appdata% surely. But why not the registry?

Cyclic dependencies are not necessarily bad. Sometimes they are essential. Try writing a linked list without a cyclic dependency.

The issue is not what components you use. The issue is the development process. You need to be able to create development environments in a robust way. These environments need to be identical. And you need to be able to build with different versions of your codebase, including different versions of your components. That isn't something that you get with naive package manager use. Yes. That's pretty much the point.

It's very hard to reproduce the exact series of steps which are undertaken when sending an email. And why bother? Since you have to handle the case when it fails for real, why not use that? The best code is the code that doesn't exist. Can't be a defect in code that doesn't exist.

I expect that if you do that you'll have clients complaining that your program refuses to send mail when it would succeed if it tried to do so.