What are your compiler settings for debug builds?

[dummzeuch 1505]

By default the IDE enables optimization and disables Range checking and Overflow checking. I've always found that odd, because I want the best possible compiler support for debugging which means:

• Optimization off
• Range checking on
• Overflow checking on

 

Edited February 3, 2020 by dummzeuch

[David Heffernan 2345]

Irrespective of what any poll says, opt off, range & overflow checks on is the correct thing to do 

[Guest]

Range checking ON for ALL builds.

[Attila Kovacs 629]

4 minutes ago, Dany Marmur said:

Range checking ON for ALL builds.

This makes Greta even more sad.

[Guest]

@Attila Kovacs,the few but important cases where this has helped... 10 hours of beer and burgers and sweat to ind those edge cases compared to the (little) extra processor power required. Also factor in what the users do when things get shaky, like print everything just in case.... No, i think in the long run it should be on. Tomorrow if i have time i'll look up the quote from Primozs book.

[Kryvich 165]

+1 for @Dany Marmur except for specially optimized and proven to be good functions/units.

Edited February 3, 2020 by Kryvich

[David Heffernan 2345]

1 hour ago, Dany Marmur said:

Range checking ON for ALL builds.

Unless performance is impacted 

[Lars Fosdal 1792]

Same as @dummzeuch

We also leave range checks on for release versions.  For us, API and database access times dwarf the array access times, and there is nothing quite like live data to throw curveballs at your algorithms.

[Guest]

Yes, in his brilliant book, "Delphi High Performance" (Packt), Primož writes "This kind of checking is so important that I always leave it in my code, even in the release version. Accessing a nonexistent array or string element may not seem so dangerous, but what if you are writing into that element? If this is not caught, your code just overwrites some other data with nonsense values. This leads to extremely hard to find problems! By default, range checking is turned off even in debug build and you really should turn it on in every program.".

 

So when i read it i did it. I immediately found a dangerous thingy in 3rd party code.

After deploying i found one or two pitfalls in my own code too.

 

Sure, for specific time-critical tasks/processes it have to be measured.

[David Heffernan 2345]

I agree with this. If it doesn't impact performance, then for sure include it in release builds. However, sometimes it really does. It does in my numerical code, but obviously that type of code is probably in the minority amongst Delphi code.

[Guest]

I can't agree with you both any more, on first hand the performance impact and on other hand catching the unthinkable, for that every now and then i will have a special version to be run on production with both checks the twist twist is i will have my EurekaLog to catch the handled exception too even in third party libraries. to find those hard to find incident and hard to imagine to begin with, once i wasted a week trying to find what cause a server to raise very wide range of exceptions, with EurekaLog alone i couldn't as the report was sending me in different directions, but with integer overflow with EL while catching the handled exception, found it and it was so silly, it was negative value in content-length in http header (simple "-" along a value less then 2^63 and bigger than bigger than 2^32), that "-" cost me 1 week and the cause was some hacking script of some sort, it was ugly lesson.

A server of mine at right this moment is configured to catch those overflows with enabled EL to catch handled exceptions is running for 23 days, not a single report, i will leave it running to hit the 49 days, right now it has 180 concurrent connections while the peak in the evening reaches 450-500, CPU usage is less than %2-10 now, and the peak might reach %25, and it uses SecureBlackBox, UniDac and RealThinkClient, i am very satisfied and proud of its performance.

There was more than 300 bugs and handled exception, i changed many code pieces to make them not raise exception to begin with like handle the bad values without exception and exit peacefully, around %90 of those bugs and reports -they are not really bugs- were reported in the first week, all of them i is hard to think of, or to reproduce in developing and debugging time.

 

The point is: having those checks enabled in production/release is not counterproductive, on contrary even enabling them for short period of time in production when performance is taking huge hit, their effect will be noticeable in: increase stability of the code and increase the developer confidence about his code. 

[dummzeuch 1505]

I recently found that my image processing code became about 30% faster after turning off range checking.

So I added a conditional define that allows me to turn it off for some units even of it is on in the project settings.

 

But as stated above: In debug builds I usually turn it on and that has saved my a** several times.

Edited February 4, 2020 by dummzeuch

[Mike Torrettinni 198]

I also set Optimization Off, Range and Overflow On, in debug.  But for release, of course Range is off. But I see some of you set it On also in release mode. I only sometimes set them on for Beta versions, never in final release.

I would rather have wrong results reported by users (and then I see that Range On would catch a bug and I fix it) vs to trigger exception to the customer. Perhaps this differs if you project is used in house vs out of country customers.

[Guest]

8 minutes ago, Mike Torrettinni said:

I would rather have wrong results reported by users (and then I see that Range On would catch a bug and I fix it) vs to trigger exception to the customer.

No need to show the triggered exception to the customer, he wouldn't even notice, simply your exceptions would fold in two categories, critical that lead to customer is not happy this exception should be knows to the developer ASAP to be fixed and the other categories like those silent, which you need them and they are not critical for your app to perform right, those will not have a dialog or any other notifications, only one message with question to the customer if he want to help by allowing to send reports of internal exceptions or not, with simple "don't ask this again", i don't see that as a burden, remember this : till next update you will already fixed 80% of those, and you are free to disable the checking for overflows.

[Guest]

Just now, Kas Ob. said:

only one message

By that i meant one message when the application is exiting.

[David Heffernan 2345]

32 minutes ago, Mike Torrettinni said:

I would rather have wrong results reported by users (and then I see that Range On would catch a bug and I fix it) vs to trigger exception to the customer.

No you wouldn't. Giving the user the wrong results is always worse than showing an error, even if the error is poorly worded. 

[Vandrovnik 214]

26 minutes ago, David Heffernan said:

No you wouldn't. Giving the user the wrong results is always worse than showing an error, even if the error is poorly worded. 

Not always... In an application drawing 3D scene, a small error in object displayed somewhere far away from the observer does not metter, probably nobody notices. Of course in a book-keeping application the situation is quite different.

Edited February 4, 2020 by Vandrovnik

[Sherlock 663]

59 minutes ago, Mike Torrettinni said:

I would rather have wrong results reported by users (and then I see that Range On would catch a bug and I fix it) vs to trigger exception to the customer.

If you expect your customers to double check your results, why should they use your software in the first place?

[David Heffernan 2345]

13 minutes ago, Vandrovnik said:

Not always... In an application drawing 3D scene, a small error in object displayed somewhere far away from the observer does not metter, probably nobody notices. Of course in a book-keeping application the situation is quite different.

I'm amazed that you can guarantee that the error will be far away from the observer. How did you do that? 

[Anders Melander 1782]

I'm currently working on a project where they (my client) have done everything they can to kill or hide exceptions. It's a nightmare. All I have to work on is vague reports from the users that "something" doesn't work, sometimes - and of course Range and Overflow Checks are disabled too, because they cause exceptions...

I've tried removing all the empty try...except blocks but then the application can't even start because there are so many bugs in it. Luckily I only have 4 months left on that contract

 

The sad thing is that I've seen this thing so many times. Some idiot developer can't figure out how to fix a bug to they hide it with a try...except and then it becomes a habit.

[Anders Melander 1782]

2 minutes ago, David Heffernan said:

I'm amazed that you can guarantee that the error will be far away from the observer. How did you do that?

Probability: There's an infinite number of locations far away vs. a relative smaller number close by. Therefore any object is almost guaranteed to be far away.

How's my logic .-)

[Sherlock 663]

Well, not showing exceptions and eliminating exception handling altogether are two different pairs of shoes, are they not? Why not log into some %APPDATA% folder every bug, that occurs and try to keep the application running. When a bug does manage to get reported ask someone to send you the (doubtlessly numerous) log files.

Apple for example highly discourages to display error messages in their iOS human interface guidelines. BUT they do encourage logging, and offer means to retrieve those logs from devices.

[Vandrovnik 214]

14 minutes ago, David Heffernan said:

I'm amazed that you can guarantee that the error will be far away from the observer. How did you do that? 

Of course I cannot guarentee it. But you wrote "Giving the user the wrong results is always worse than showing an error, even if the error is poorly worded.", so I gave you an example, where error message would be worse than ignoring the error.

[Anders Melander 1782]

3 minutes ago, Sherlock said:

Well, not showing exceptions and eliminating exception handling altogether are two different pairs of shoes, are they not?

Killing all exceptions with empty try...except and disabling range and overflow checking amounts to the same thing.

Not showing exceptions is a different topic. I don't believe the users should see the raw exception messages if it can be avoided, but when something goes wrong, that the application cannot reliably recover from by itself, then they need to know there is a problem and what to do about it.

[David Heffernan 2345]

16 minutes ago, Sherlock said:

Well, not showing exceptions and eliminating exception handling altogether are two different pairs of shoes, are they not? Why not log into some %APPDATA% folder every bug, that occurs and try to keep the application running. When a bug does manage to get reported ask someone to send you the (doubtlessly numerous) log files.

Apple for example highly discourages to display error messages in their iOS human interface guidelines. BUT they do encourage logging, and offer means to retrieve those logs from devices.

Better hope that the incorrect information that you show to the user is inconsequential.