We Keep Coding

How to report standard exceptions to the user?

Consider a C# GUI application which uses a FileStream to read a file, chosen by the user through an "Open File" dialog.
In case the read fails with one of the exceptions, what is the correct way to report the failure to the user, in an user-friendly manner?
Should I invent my own message for each of those exceptions, or is there a way of obtaining a localized, user-friendly message that I could present verbatim to the user?
Edit
I'm asking whether .NET itself is able to provide me with a descriptive string that I can present (and which would be consistent with other .NET programs). I know that I can roll up my own, but I'd like to avoid that if there's a standard alternative.

You can have a set of localizable user exceptions with one of them being say FileUploadError. You can put a localized general information there. Throwing a few technical details might be a bit challenging, as it can be quite hard to get the right balance between technical details and a simple step that a user needs to take to fix an error.
My suggestion would be:
Have one user level FileUploadErrorException
Have a details property in it
Depending on the actual exception, suggest a user to try a few things

If you are catching an exception thrown by one of the .Net framework's File classes, then it is likely that the contents of the exception's .Message property will already be localized. The .Message property is supposed to contain localized, human readable text. How 'friendly' it is depends, I guess, but it might contain something you can embed within a more general and friendly paragraph.
Assuming you might write some method AlertUserWithMessage() to display the error to the user, this might be useful:
try
{
fileStream.Read(...); // or some other operation
}
catch(Exception e)
{
AlertUserWithMessage(e.Message);
}
If you want to include additional information that might be helpful to a support person diagnosing the problem, then you can also get the stack trace as a string from the exception.
try
{
fileStream.Read(...); // or some other operation
}
catch(Exception e)
{
AlertUserWithMessageAndStackTrace(e.Message, e.StackTrace);
}

Exception messages are by nature technical and describe what went wrong (at implementation level), as opposed to how to solve an end user's problem. On the other hand the intent of an error message presented to the user is to explain what failed and what action to take to remedy the problem. Exceptions messages and end-user error messages don't have the same purpose and aren't written for the same audience.
So for decent user experience, it is much better to map these exceptions to localized user-friendly advice on how to get around the problem. Sure, for technical users it could be nice to have some diagnostic feature that could give details of the exception (in which case having exception messages in English doesn't matter that much--English is really the world's technical language), or just point them to a log with all the details. But just throwing an exception message, even localized, at an end user is likely to baffle them.
For this reason I don't think localizing exception messages is much use. It's true that the .NET framework has localized exception messages for major languages, but I think that's more because there are developers who use these languages as their base language and do not necessarily have a good command of English. So the audience of these localized exception messages is still developers, not end users of a software product built in .NET.

Send Email in Global Exception Handler?

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.

Localization in a WCF server

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.

How to find if app has been installed before?

Is it possible for a .NET application to leave a trace so that it can be found if the application is re-installed?
Of course, a trace that is difficult to be removed.

Create a file
Create a registry key
Create a global variable
A combination of all above
...and then check for existence the next time install is attempted.
While it is better practice to remove applications in their entirety, I assume this is for 'trial' software (one time install) purposes or a similar reason.

Well, generally, if you un-install something, you'd hope it completely removes itself, and doesn't leave a trace of the fact that it was there. Otherwise, if it doesn't, it hasn't really un-installed.
This is language-agnostic anyway.
So the answer is: Yes, but don't do that.
What problem are you really trying to solve?

Many application leave behind traces (eg in registry) to detect previous installation. However tools like RevoUninstaller can be used to completely remove those traces. One easy way of doing so is to send the machine id to your server.

I've done some Googling to find better information (with no success) but I can remember mention of something referred to as the "Manufacturers Section" of a hard drive, an area which is outside that of normal storage to which it's possible to write information that won't be lost if the drive is re-formatted. The specific product I'm remembering was AutoCAD.
The fact that you are asking for something that is "difficult to be removed" leads me to believe that you are looking for something like this?
It's unlikely that the use of this sort of technology would make you very popular with your customers, particularly with the bad feeling directed towards DRM, rootkits and the like.

Should Exception Messages be Globalized

I'm working on a project and I'm just starting to do all the work necessary to globalize the application. One thing that comes up quite often is whether to globalize the exception messages, but ensuring that string.Format uses CultureInfo.CurrentCulture instead of CultureInfo.InvariantCulture. Additionally this would mean that exception messages would be stored in resource files that can be marked as culture-specific.
So the question is, should exception messages be globalized or should be be left in either the InvariantCulture or the author's country; in my case en-US.

Exception messages should rarely be displayed directly to the user. You need to think of the consumer for each string. Obviously pieces of text in the user interface need internationalizing, but if an exception message is only going to be seen by support (or is going to be visible to the user and then emailed to support when they click a button) then where's the benefit of translating it?
If you go too far, you could not only waste time and effort (and i18n can take a lot of effort) but you'll also make your support life harder as well. You really don't want to have to read log files written in a foreign language and translate them back to your native tongue.
It makes sense for Microsoft to internationalize their exception messages, because they will be read by developers from all over the world - but unless you're multinational with developers in multiple countries who don't share a common language, I wouldn't translate message which are really meant for dev/support.

typically, I don't.
Globalize strings that may be seen by a user, and you don't let your exception messages percolate up to the UI, right?
Right? :)

If you are going to be the one to deal with the exceptions, then either leave them in a language you can understand, or give them codes so you can look them up in your native language.

I assume by globalize, you mean i18n compliant which is usually called internationalize. Yes, internationalize all visible parts of the GUI, including diagnostic messages. The log file, which is where developers should go to get the real information such as the stack trace, should not be internationalized.