You (as developer) is interested in getting as much bug reports as possible. First, you have to select a reliable send method for delivering reports from users to you. However, it may be not enough. Sending may fail for many reasons:

Bug report will not reach you in all these cases. Then what?

Well, we have several techniques for dealing with network delivery problems.

Setting up fallback send methods

First, you may set up multiple send methods. You arrange them in a preferred order:

Two send methods were set up

EurekaLog will try to send report via first defined send method - say, a bug tracker (FogBugz in the screenshot example above). If sending fails for whatever reason - EurekaLog will attempt to send via next available send method (SMTP client in the screenshot example above). And so on - until send succeeds or no more send methods are set up.

Important Note: shell/mailto send method have no way to determine if a send was completed successfully. Therefore, this method always return success. So next send method will never be called. For this reason, shell/mailto send method should always be last method to be used.

See also: advantages and disadvantages of each send method.

Recommended order of send methods

We recommend the following order:

If you don't want (or can't) use some method in this list - just exclude it and place the rest in this order.

For example, if you want a reliable "mail only" delivery - use this:

If you can't afford storing password - use this:

(however, this has greater chances to fail sending)

This is just recommendation, not final rule. For example, you may use this sequence:

1. Mantis

2. Shell

It's your choice, it's up to you.

Note: usually there is no big reason to enable both SMTP client and SMTP server modes. Use either first or second, but not both. I.e. if you can afford storing the password from your real e-mail account in application - use SMTP client. Otherwise use SMTP server.

Saving bug report's backup

Second, if send fails (meaning all send methods) - EurekaLog may be set up to copy bug report file to My Documents folder. See "Save bug report copy to My Documents folder" option. The user will be notified about it (assuming you have set up a failure message to be visible). The idea is that user can pick up this file and send it to you (developer) manually via any available means. You may change backup file location and/or file name by using OnCustomFileName event handler (you are interested in AFileType = ftZIPCopy).

Additionally, report can be copied to the clipboard (both as file and as text simultaneously) - via "Copy bug report to clipboard" option. The idea is that user will be able to launch e-mail client (or go to support form on your web-site, etc.) and paste report into message.

Important Note: shell/mailto send method have no way to determine if a send was completed successfully. Therefore, this method always return success. So fallback/recovery/saving will never be called. For this reason, we do not recommend to use shell/mailto send method, if you are going to use any of fallback/recovery methods.

Perform custom recovery

Finally, you may assign event handler to be called on send failure and perform you own custom actions (like saving bug report file to some sort of storage). For example, you may assign OnExceptionAction event handler and look for (AEurekaAction = atSent) and (AExecute = False). AAdditionalInfo will hold error message from sending. You may perform your recovery, and even switch AExecute to True to indicate successful send (so error message and creating backup will be skipped). If you did not alter "success" state of failed send - then OnExceptionError will be raised with AEurekaAction = stSent. You may perform your recovery there, and even swithc ARetry to True to retry sending.

See also: How to get file name for bug report?

Automatic resending of failed bug reports

EurekaLog do not have such feature, because of many implementation issues.

If send fails - EurekaLog can add report to some sort of offline storage. That is not an issue. Now, many questions arise:

There are too many questions without good answers. That is why this aspect is currently left for your own implementation. You may create a subfolder in APPDATA folder; copy backups in that folder; resend when you can; may be create a standalone send application; clear subfolder when necessary. Refer to Implementing offline storage for bug reports article for a sample implementation.

See also: