Many people probably remember the days where ActivePDF had very simple basic error handling. You would call the Method, and it would return a simple integer value which you could then look up to see what it represented. We can still see this type of Error Handling used today in our Toolkit product...
varReturn = tk.OpenInputFile(varPath & "input\" & varFileName)
If varReturn <> 0 Then
log("'" & Method & "' failed with a '" & varReturn)
varReturn in this case will be an Integer. A "0" indicates a Success, while something like a "-1" would indicate a failure to open the input file.
However, many of you have probably noticed that in most of the ActivePDF products we no longer use the basic Integer return value anymore, and now actually return an Error Object. And even Toolkit which still uses the Integer system, have options to help gather more information about what is happening when you run into an error without having to sort through the logs every time you run into a problem.
In Toolkit for example, there are several properties that will help you gather more information about what is going on than the simple integer value normally used. We can see some of these properties in the sample below...
varReturn = TK.OpenInputFile(varPath & "input\" & varFileName)
If varReturn <> 0 Then
log("EncryptionError: " & TK.EncryptionError)
log("ExtendedErrorCode: " & TK.ExtendedErrorCode)
log("ExtendedErrorDescription: " & TK.ExtendedErrorDescription)
log("ExtendedErrorLocation: " & TK.ExtendedErrorLocation)
These properties should help return additional data about what is happening including a written description about the problem, and the actual location of the problem within Toolkit. So if we use this to try opening a password protected file for example we would simply see a -1 returned, indicating a failure to open the input file normally. But if we use the extended error logging we would see the following information...
OpenInputFile(Input.pdf) = -1
ExtendedErrorDescription: Owner password (獤ﻟ翼) is not valid
Here in the error description we can clearly see that the Owner Password is not valid, and would automatically know that this file is being password protected and would need to provide the password information in order for Toolkit to be able to successfully work with this file.
Then we also have a new Error Object in some of our products such as DocConverter and WebGrabber which again help us gather significantly more information when an error occurs, than what was previously possible. Below is an example of extended Error Handling using our DocConverter product...
public static void ErrorHandler(string strMethod, DCDK.Results.DocConverterResult actual)
StreamWriter log = null;
// Check to see if logfile exists for this thread, if not create one, if it does append to it.
if (!File.Exists(Application.StartupPath + "\\ErrorLog.txt"))
log = new StreamWriter(Application.StartupPath + "\\ErrorLog.txt");
log = File.AppendText(Application.StartupPath + "\\ErrorLog.txt");
// Write error message to LogFile
log.WriteLine("Method: " + strMethod);
log.WriteLine("Status:" + actual.DocConverterStatus);
if (actual != null)
log.WriteLine("Error Status: " + actual.DocConverterStatus.ToString());
log.WriteLine("Error Details: " + actual.Details);
log.WriteLine("Error Origin.Class: " + actual.Origin.Class);
log.WriteLine("Error Origin.Function: " + actual.Origin.Function);
if (actual.ResultException != null)
log.WriteLine("Error Exception.Message: " + actual.ResultException.Message);
log.WriteLine("Error Exception.StackTrace: " + actual.ResultException.StackTrace);
var inExc = actual.ResultException.InnerException;
while (inExc != null)
log.WriteLine("Error " + inExc + ".Message: " + inExc.Message);
log.WriteLine("Error " + inExc + ".StackTrace: " + inExc.StackTrace);
inExc = inExc.InnerException;
You can still see a simple status of the conversion by using the "actual.DocConverterStatus" to quickly see if the conversion was a success or a failure. But now with the full error object, we can actually the specific error details, the class and function where the error originated, a detailed exception message, and even loop through the stack trace. In this example if we sent in a password protected word document for example, the DocConveterStatus would simply tell us that the conversion failed with "OpenInputFileFailed". But if we use the extended error handling as described above, we would see the following information...
9/8/2017 4:09:18 PM
Error Status: OpenInputFileFailed
Error Details: The password is incorrect. Word cannot open the document. (C:\...\Input\$1582c7150859$test.docx)
Error Origin.Class: WordConverter
Error Origin.Function: OpenFile
Using this additional information we can very quickly and easily see that the file in question was Password Protected, which prevented us from being able to open the file. To resolve this we simply need to remove the password protection from the file, or provide the password information to DocConverter so it is able to access the file and process it normally.