I want to add global exception handling code to C# WPF apps and, although it seems rather rakish (nobody else seems to do it), I want to send email to the developer with exception info. The main problem I can think of happening here is if the developer ends up changing his email address after the software has been deployed. Perhaps an email to the department (such as a listserv type of email broadcast address) would be more appropriate? Has anybody used this sort of methodology, and if so, what solution have you come up with to make sure that somebody gets the exception-generated email?
Is this the best solution:
// in exception code (pseudocode)
try
SendEmailToTheCoder();
catch
on EmailAddressNotValid:
try
SendEmailToTheListServ()
catch
on EmailNotSent:
LogExceptionDataToLog("Bla");
...or has my brain gone pear-shaped again (I don't know what that means, but it's British, so it must be wickedly funny)
The best thing to do is to keep the details of the messaging outside of the application.
For instance, you may log errors to a text file or some other kind of log, then have an external application or Windows service monitor that log and decide what to do -- such as sending an email, or creating a digest of all messages of the day and emailing it, or a similar action.
This way, you can optimize and modify what happens in case of these errors, without having to change your program code. You can also reuse that system with other applications that also just log errors to a text file, which has a lower probability of error than connecting to an SMTP server and sending a message.
I would just create a distribution group, something like developer#yourcompany.com and add people responsible for the program part of that distribution group. If one developer leaves the company, nothing in your code needs to change and no trying one thing first and then another one.
Better yet, use a logging framework such as log4net (nlog is also popular); you can configure it to log to different places (xml, database, email, etc). If you do log to email, I'd always send it to a distribution group, anyway, even if that distribution group is composed of only one member.
Related
I have written a custom pipeline component assembler to modify the response ACK HL7 message.
I have invoked Assemble(pContext) of Microsoft.Solutions.BTAHL7.Pipelines.HL72fAsm in the implemented method Assemble(pContext) of IAssemblerComponent interface
gives me result IBaseMessage
which is an HL7, then I do my manipulations on it to fix one of the fields and return that modified IBaseMessage.
All these works just fine, I tried EvenLogger to verify it.
But still the Sender application doesn't receive the modified message, it receives the auto-generated message.
Is there something I'm missing out, why do I not get the custom assembler result out from the SendPipeline of 2 way receive port
Note : BTAHL7 Configuration explorer is configured for original mode. The send pipeline on RequestResponse receive port is set to my custom pipeline
My suggestion is after all the more important points.
The first thing you're employer or customer should say is NO. That is invalid HL7 and you cannot support that.
But, if they are unable to unwilling to comply, the next thing you need to do is inform your management that their non-compliance will cost you a lot of extra time and money to accommodate. To fully support this change will likely cost more then implementing the business messages, I am totally serious. This is not a problem with BizTalk Server, you app or you.
Depending on the relationship, your management can legitimately ask them how they are going to pay for this customization. It's going to cost your side a lot more to break HL7 to comply with them than it will for them to fix it.
Next, and perhaps most important, due to the nature of it's message content, HL7 has very strict completeness requirements, which they are fundamentally breaking. The Trading Partner needs to fully document this requirement to take ownership of it because there is a huge consequence, they are breaking tracing/tracking on you end.
This means that it will be substantially more difficult to investigate and resolve messaging issues for you, not them. This might raise legal or compliance issues your side needs to be aware of.
So, provided you technical, medical and legal teams are all satisfied, the first thing I would try is a Pipeline Component that simply swaps the two values, MSH10 and MSA02. That way, they will receive both values.
Finally, here's a novel solution. Since this is their problem, and a problem for every one of their trading partners, what if you offer help them fix it. All then need to do is what I suggested, swap MSH10 and MSA02 on the received message.
I am developing a custom Steam bot from scratch that will react to numerous callbacks emitted by Steam, like OnConnected, OnTradeOfferReceived etc. The callbacks contain parameters like IDs or data.
I wish to give the user freedom to define how should the system react when a specified callback is received.
This can be easily solved by forcing the user to manually program the "reacting" parts, but I really wish to avoid that, because a big part of the possible user base are not programmers at its slightest.
The already existing SteamBot on GitHub does this, leading to questions like "how to build SteamBot.sln".
I thought of a GUI for specifying conditions and executing actions if the conditions are true, but I fail to come up with how to parse them in code without going through each and every option.
By actions, I mean replying to a trade offer, sending a chat message to someone, adding an item to a live trade etc.
Maybe the GUI should generate the actual code (based on user's input) and recompile the bot? Any help or suggestions would be appreciated.
I am fairly well versed in using localization in a simple WPF UI application.
I am now in the process of developing a WCF client/server architecture; I want to be able to create various types of exception in the server, and have the error message in the culture of the client.
This seems straightforward enough - somehow we will identify the culture being used by the particular WCF client at the time.
However, I want the messages to potentially also be logged into the server's logfile in one language (typically English) to allow easier support of the application.
There are various assemblies used in both the server and the client side; each assembly is going to have a string table of error messages. Therefore when an exception is created, it needs to have the resource ID and the resource manager for that given assembly to hand. Without sub-classing each available exception type, I cannot see how to get around this. This seems like a lot of work for a problem that has surely been encountered before?
Example
Server.A.dll
Error Resources: MyErrorString1, MyErrorString2
Resource Manager: ResourceManagerA
Server.B.dll
Error Resources: MyErrorString3
Resource Manager: ResourceManagerB
So ideally I need to have access to the resource manager for a given string at the time I need to either log the message to the file or send it back over WCF as a fault; but I don't want to lose the ability to catch types of exceptions by using one generic exception class.
Does anyone have any experience of this problem, or any cool suggestions on how to go about implementing it?
Thanks in advance,
Steve
I don't think that is good idea to show plain Exception messages to users. Instead, I would catch them log them and show friendly message in UI. That way you won't need to subclass anything...
If it is a technical exception, there is no need for details that the user won't understand anyway. Just display a generic error message.
As for expected error condition, they should be cataloged somewhere. Then you just need to exchange error codes between client and server and do the localization on the client based on the error code.
Writing a pure API seems to be bring up some challenges. For example, I am used to writing winforms/asp.net apps where if the input I have is invalid, I can programatically bring up a dialog box/webpage.
However, an API has no knowledge of the GUI app it may be executed from. If I have a method called TakeString (String s), and the string (s) cannot be more than 5 letters, how would I return control to the client if it was so? An exception seems like overkill? A simple return won't work if I am returning something in the method.
Thanks
An exception is exactly the right thing to do. You document that you'll only accept a string as input if it's 5 letters or fewer, and throw ArgumentException otherwise. Why would that be overkill?
In this case, you don't even need to worry about alternative mechanisms if the client can't detect the validity of what they're passing you: if the calling code has any doubt about the arguments they're going to pass you, it's not exactly beyond the wit of man for them to check it themselves.
Trying to make the API forgiving of invalid input is a recipe for disaster. Validate the input as stringently as you can, within reason. If you force the client to behave well, you'll have a lot fewer problems later on.
An Exception is the best way to handle this.
By definition, if the user is supplying invalid data, this is an exception. The client app needs to be responsible for handling the exception and prompting the user to re-enter as necessary.
Your API (as you already pointed out) should be ignorant of the client app, including what type of app it is, so all your API has to do is say "Hey, that's invalid!" and let the developer of the client app figure out how to handle it.
For a simple example if you try the following line of C# code:
int myInt = Convert.ToInt32("SSDS");
the .NET Framework doesn't try to re-prompt the user. It just throws an exception.
I am wanting to discover what possible standard .net exceptions can cause stack traces to include sensitive information.
It is my understanding (correct me if I am wrong) that if a SQL connection fails then the exception message created will include the connection string which in turn might include the user name and passowrd (if not using integrated security).
We log the exception message out to log files that might be read by people that should not see that information.
What other exceptions can include information such as this that you know of?
The application in question uses Web, WCF and DB (SQL Server).
Thanks
Personally I don't think that you are going around this the right way. Trying to identify the number of exceptions that could have information in them is going to expose you to risk more than likely as one item will get missed, it just happens.
I would switch focus a bit and try to identify where you can log them to be a secure location.
Another unknown to think about here is that you could have a message created by a developer that contained sensitive information, and identifying those would be very hard.