Question

I have a method that generically deserializes a stored object from a users provided filepath and object type. The method works fine, except for when the user provides an invalid filepath. I would like my method to return a null in this case, but when I attempt to return null I get a compilation error. I tried to use a nullable type but get a compilation error. Instead, I typecast an object and return that, but it causes a runtime error. I would like to know if anyone knows the proper way to allow for returning a null. The code is as follows:

        public static T RestoreObj<T>(string datafile)
    {


        try
        {
            var fs = File.OpenRead(datafile);
            var bf = new BinaryFormatter();
            var obj = (T) bf.Deserialize(fs);
            fs.Close();
            return obj;
        }
        catch (Exception e)
        {
            MessageBox.Show("Could not load. Accepts valid *.dom files only. " + e);

            // TODO: how to do this? this will throw a runtime error, and if null returned, a compilation error
            var o = new object();
            return (T) o;
        }
    }

After taking Eric Lippert’s quality comments in to consideration I revised the method to look like what you see below. The advantage of using ‘using’ is that it automatically generates a try..finally block that will call the dispose method (FileStream implements IDisposable, if it did not their would be a compile error). Another nice thing is that the exception thrown is relevant to whatever is actually happening instead of what I have above.

        public static T RestoreObj<T>(string datafile) 
    {
        using (var fs = File.OpenRead(datafile))
        {
            var bf = new BinaryFormatter();
            var obj = (T)bf.Deserialize(fs);
            return obj;
        }
    }

Answer 1

I would solve the problem by not writing that code in the first place.

A method should do one thing and do it well; you are mixing up deserialization code with error reporting code.

Don’t do that. A better way would be to have the deserialization method throw an exception, and write different code that handles the exceptions and reports errors to the user.

More generally, it is dangerous to have a method that eats exceptions and then returns bogus data. That is just creating problems down the line when unsuspecting code that calls your method expects to get good data back.

While we’re on the subject of code quality, you should be using “using” blocks to ensure that the file handles are closed if an exception happens. Do not explicitly do a fs.Close() — rather, do using(var fs = ... ) and let the compiler generate the disposal that closes the file.