Send Email Upon Error
-
Sometimes you get assigned to a project that is so fucked up that you can't help but laugh when you start to understand how it works. And yet at the same time you want to murder the families of the original developers.
When you are coding there are just some things you just don't do. I mean no one in their right mind would ever think of doing things kinda way. For some reason they all seem to congregate in this mess of a project. The must frustrating yet most laughable at the same time is the boolean logic in the database. They Inverted it. 1 for false and 0 for true. Even you MIS guys can understand things just don't work that way.
As you can imagine this code generates a lot of exceptions. The original developers had the fore site to have the app send an email to themselves when ever an exception occurred. Basically a little message where the exception happened and a stack dump. However, there is sometimes an error when sending out the email. So guess what, it sends out an email letting you know that an error happened with the previous email. I laugh every time that happens, then when I realize that I have no idea where the original error occurred I cry a little.
-
Hmm, what happens in the case of a minor problem with the email code? Error generated when sending email, but email still gets sent anyway. New email gets generated that causes the same error and yet another error email. Infinite loop of emails + crashed and overloaded email server?
-
In UNIX shell scripting, 0 is true and all other values are false. This is because programs return non-zero values when they die horribly, and zero when they pass away peacefully. This allows the program to offer some additional info about just how horribly it died in its specific selection of exit code.
-
@Critter said:
In UNIX shell scripting, 0 is true and all other values are false. This is because programs return non-zero values when they die horribly, and zero when they pass away peacefully. This allows the program to offer some additional info about just how horribly it died in its specific selection of exit code.
Ok I wasn't aware of that. But this isn't a project based upon Unix shell scripting. This is a .Net project, and you would think that when they coded things they would realize they got thing backwards. They had to invert all the if logic when testing upon the data from the database.
-
Many (all?) SQL Server system stored procedures also return a zero error code when they are successful...
-
In ntstatus.h
#define STATUS_SUCCESS ((NTSTATUS)0x00000000L)
In winerror.h
define ERROR_SUCCESS 0L
#define NO_ERROR 0L // dderror
#define SEC_E_OK ((HRESULT)0x00000000L)For boolean logic its true that zero is false and non-zero is true. For many functions, procedures, whatever that return some form of status, there are far more error cases than success cases so zero for success and non-zero for some error is not actually all that uncommon. There's a long history of this in Windows as evidenced by the standard error code definitions. It comes down to a question of context. In these cases, when you consider the boolean state of the return code, its answering 'was there an error' rather than 'was that successful'. You have to consider the context of the values in the database to see if they make sense somewhere early on, in which case maybe the only silly part is not reversing the logic before putting the values in the database.
-
@IHateEverybody said:
There's a long history of this in Windows as evidenced by the standard error code definitions.
It's far older, inherited from the predecessors of unix. It doesn't actually make a great deal of sense on modern systems, but people keep dragging the convention around out of habit.
-
This convention is only valid when applied to condition codes.
It's no reason to switch true and false's sense, though. That's just madness.