How to trap Email authentication failure ?

[Paul]

Hi,

I'm having a problem with my application locking up when EurekaLog
fails during the email transmission.

I have deliberately entered incorrecrt authorization credentials to
simulate an email transimission faiure. The SMTP error code is "535 Incorrect authentication data" as would be expected, but I can't see where or how EurekaLog is supposed to correctly handle such an event.

Ideally I want this all to be in the background i.e. no dialogs. When I
do switch the "Show the send dialog" and "Show success/failure msg." notifications on, I can see that the send dialog is displayed, and then the exception "EEurekaLogSocketError" comes up with the message being the 535 error. After that, the send dialog is displayed, but the application then sits, locked at that point.

How can I avoid this. Everybody must experience email trsnsmission
failures at some point, even when the credentials / destination etc are
correct.

I don't want to switch to using web based transmission at this point...

Thanks,

Paul.

[Paul]

Just a piece of further information. I can repeat this using the "GUI"
demo, with a couple of modifications.

The key thing seems to be the "catch handled exceptions". If using SMTPClient and I specify invalida authentication credentials, the resulting error behaves as I previously said. That is, the SMTP error is displayed, and then the "Send" dislog is redisplayed, but just sits there.

Without the "Catch handled exceptions" enabled, the "Sorry, sending the message did not work" information dialog is displayed and the application contines.

As I want and need to catch handled exceptions, how can I get around
this ?

[Alex]

Hi,

Actually, "catch handled exceptions" is a special debugging option, which is not designed for production use.

That should be quote obvios: if you exception is catched - then your code knows what to do with it. May be, it wants repeat operation, may be it wants perform cleanup, may be it wants recover, may be it wants to switch to another method, etc, etc. Messing with this logic isn't wise.

You usually enable "catch handled exceptions", when you have unexpected behavious in large piace of code. There are many except blocks, some of which is set by 3rd party code/component, and there is an error message or something, coming from nowhere. So, you enable "catch handled exceptions" to see, what is it. Note, that this happens, when code fails to do proper processing - it catches exception, when it shouldn't. That's it. The whole purpose of "catch handled exceptions" switch.

If your code requires using "catch handled exceptions" for normal, daily operations, not as exceptional debuggin case - than your code is wrong. I REALLY recommend rewrite it.

This is especially bad, as many code uses exceptions for rare, but legal operations, which aren't errors. For example, EAbort to cancel current operation or some Indy exceptions.

Ideally I want this all to be in the background i.e. no dialogs.
Well, I think that you may be interested in setting ShowInternalSendErrors global variable to False (unit ExceptionLog).

As I want and need to catch handled exceptions, how can I get around this ?
As I said - you're doing something VERY wrong. But if you really want it - you should manually turn off and on this option while processing error.

It's boCatchHandledExceptions in CurrentEurekaLogOptions.BehaviourOptions. Please, refer to help file for more detailed description: http://www.eurekalog.com/docs/teurekamoduleoptionstype.html

You need to use ExceptionActionNotify event: http://www.eurekalog.com/docs/exceptionactionnotifyhowto.html to exclude/include this option.

But, please, think twice before doing this.

[Paul]

Thanks for the clarification Alex. Our application does "recover" to
some extent from exceptions it either generates on purpose or from unexpected problems. My intention with the "Catch handled exceptions" was to be able to report all such issues without any extra effort on my part.

The answer for us is actually "ShowLastExceptionData" as per one of
your examples. I will have to go through all of our code and insert
this in the relevant exception handlers, but you don't often get
anyththing for nothing so it will be worth it. I've already tried this
and it handles things as I'd hope - we can carry on with the exception reporting as we have it, and also raise the exception to the level EurekaLog bug reporting if we want to - which we generally will want to.

This was the last piece in my evaluation, so yo can expect to see an
order from us today.

Paul.

[Alex]

Hi,

Thank you very much for the feedback!