Delphi Programming Tips & Tricks

Every once in a while, every developer encounters random bugs that happen only in production and cannot be reproduced at will. If you cannot reproduce it, you can hardly fix it. In such situations, recording exceptions with various error loggers can help us find the culprit and fix the error. However, sometimes the information collected simply does not contain enough data to do so. This post is inspired by the following Stack Overflow question How to know the exact line number that produce an exception where the logger has recorded an exception and its call stack. Argument out of range At address: $002CDD4B (Generics.Collections.TListHelper.CheckItemRange(Integer) + 62) Call stack: MyApp $00BB153D Grijjy.Errorreporting.backtrace(Pointer*, Integer) + 8 MyApp $00BB1427 Grijjy.Errorreporting.TgoExceptionReporter.GlobalGetExceptionStackInfo(TExceptionRecord*) + 74 MyApp $001C4D83 Sysutils.Exception.RaisingException(TExceptionRecord*) + 38 MyApp $001E903D Sysutils.RaiseExceptObject(T

Variations of the above question get asked on a daily basis and there is an increasing number of bug reports that state basically the same thing. Android applications compiled with older Delphi versions work, and simply recompiling them with Rio produces a non-functional application. Is Delphi Rio broken? NO. So what happened? First of all, mobile development regardless of the toolset is a fast moving target. New versions of mobile operating systems are released on a yearly basis, introducing new features and breaking old behaviors. Applications submitted to both the App Store and the Play Store must satisfy some minimal requirements defined by their respective owners. While Apple has always been pushing for faster adoption of newer iOS versions, forcing developers to stay current and compile their applications using newer SDK versions, as of recently Google has started doing the same. Just like there is a minimum requirement for submitted iOS applications to use minimum iOS 1