• Vera (unregistered)

    Who wants to bet there were multiple people who set up rules to automatically move any exception-mails to recycling?

  • some guy (unregistered)

    And of course, the SmtpClient would need to be .Disposed, but isn't ...

  • (nodebb)

    I can definitely see the compiler doing a tail recursion optimisation and preventing a StackOverflowException from ever happening, but in that case it just becomes an infinite loop that hangs the thread, but might unexpectedly end if the problem that causes the failure of SendEMail is resolved.

    (In reality, it might well end sooner than that, as in, for example, the process running out of memory for allocating another SmtpClient object.)

  • Darren (unregistered)

    If I had a penny for every time a manager had said that IT should send out an email to let people know that email was down, I'd probably have enough to buy a chocolate bar. Joined up thinking seems to be sadly lacking for a lot of people.

  • (nodebb)

    Bonus points for not using the receivers parameter.

  • (nodebb)

    At a previous job, a certain web service application sent out an email to the ops team every time the server served up an HTTP 500 error with the exception stack trace and details etc. That worked ok at first, but then the first time someone pushed a bug that broke 100% of all requests...well let's just the email server wasn't too happy, and we very quickly added some rate limiting to the email sending.

  • (nodebb)

    I worked for a company once that failed to send more than 80% of emails successfully, and called it industry standard. Using email to alert people is unlikely to work, either no one sees the email because they are asleep, or so many emails are sent than they filter them all out.

  • (nodebb) in reply to Steve_The_Cynic

    .NET's JIT doesn't do tail call optimization. And if it did in the future, it won't apply here because (1) there's a SEH block (the try/catch), and (2) this is probably the old .NET Framework which had a very weak JIT.

  • (nodebb) in reply to colejohnson66

    OK, fair enough. Thanks for the extra info. In that case, it becomes a race between running out of stack for the recursion and running out of memory for more SmtpClient objects. These days, it seems highly likely that the stack runs out first, but...

  • (nodebb) in reply to Steve_The_Cynic

    No recursion.

    In .NET, an unhandled exception in a catch block will crash the program.

    Or throw it back up one level in the call stack.

    I forget which...

  • Hans (unregistered)

    Been there, done that. Cleaning up that mailbox was quite a chore as Outlook/Exchange at that time could handle deletion of just a few 1000 at a time.

  • John (unregistered)

    Crashed mail server. Haven't heard on one in the past 20 years.

  • Álvaro González (github)

    I confess that when I was young (i.e. a long time ago) my 404 Not Found error pages would typically include functionality to send me an email depending on the referrer header. Even then I knew you have zero control on external links, but I was apparently very concerned of broken internal links slipping into the mostly static sites I built back then.

  • (nodebb) in reply to Joe_D

    In .NET, an unhandled exception in a catch block will crash the program.

    Yes, but in this case, the SmtpClient's exception inside the recursive call is handled inside the recursive call. Unless try blocks aren't allowed inside catch blocks...

  • (nodebb)

    I supported a couple of .NET apps that sent an email when an exception occurred. Fortunately it wasn't too often, but the developers (well before my arrival) decided what was really needed in that email was the Session State field. If you've never seen a .NET session state, imagine a block of what looks like Base64 encoded text filling the screen, only worse. Of course, the FTW is that Session State is encoded. Boy, was that ever useful!

  • xtal256 (unregistered)

    Remi: " Easy Reader Version: I hate email, mostly because the signal-to-noise ratio, even in my work inbox that only co-workers (or services I'm required to use) send messages to is just terrible. 80-85% of the email I receive is useless to me. "

    You think that's bad, try being in a Teams group chat!

Leave a comment on “Reliability Test”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article