0

What are some pro's and con's of validating your performed the task intended?

public static bool UploadFile(string filename)
{
    // 1. upload the file
    // 2. check to see if the file now exist on the server and return status
}

vs. 

public static void UploadFile(string filename)
{
    // 1. upload the file and hope it's on the server now, or check with another method to see if the file exist on the server
}
TreK
  • 247
  • 2
  • 5
  • 1
    possible duplicate of [Why are exceptions considered better than explicit error testing?](http://programmers.stackexchange.com/questions/166039/why-are-exceptions-considered-better-than-explicit-error-testing) – gnat Feb 04 '15 at 23:00
  • 1
    possible duplicate of [Defensive Programming vs Exception Handling?](http://programmers.stackexchange.com/questions/139171/defensive-programming-vs-exception-handling) – Adam Zuckerman Feb 05 '15 at 00:25
  • 1
    Both of your methods are fine (or rather could be fine), however the naming is incorrect. A method `bool UploadFile` should be named to `bool tryUploadFile` so that it indicates you can't be sure after execution that the file was uploaded. You need to check yourself if you care regarding the success. If the second one is called `void UploadFile` it *must* fulfill its contract when beeing called. This means, the file must be uploaded. If the function fails to upload (e.g. no notwork connection available) it broke its contract - so the only way out is throwing an exception. – valenterry Feb 05 '15 at 00:56

2 Answers2

2

Your example is flawed.

When uploading a file to the server, if something wrong happens, such as a timeout, or a server-side error, this would result in an exception. If this doesn't result in an exception, the underlying methods you are using which didn't threw one are a problem, and you should switch to a library which does things correctly.

For instance, if the HTTP library you use doesn't throw anything when receiving HTTP 500 from the server, the library sucks. Use a better one.

This also means that both of your pieces of code are wrong.

  • In the first case, you don't check if the file exists. It exists, obviously, because you just uploaded the file and the server returned an HTTP 201 which was processed by the underlying HTTP library as a success response. If it doesn't exist, you shouldn't reach the second point of your method, because an exception should have been thrown.

  • In the second case, you don't hope that something works. You know that it works.

So:

public static void UploadFile(string filename)
{
    // 1. Upload the file.
    // 2. The file is uploaded. It's there, on the server.
}
Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
0

From the way your question is phrased, it sounds like you're generically asking if you should verify something executed correctly. The answer is yes.

If it's something simple like a system call, then you would return the runtime's exit code For example:

Runtime.exitValue()

This is assuming whatever you executed itself returns a proper error. If I run a Bash script from Linux and it returns 2, your Java code needs to know what that means and what to do.

In Java the big things to catch are Exceptions (and NOT just catching them as generic exceptions). ArithmeticException (dividing by 0), ArrayOutOfBounds (accessing part of an array that isn't defined), NullPointer, etc. Whenever you run into unexpected or risky behavior, it's always safer to catch yourself.

The extent to which you verify as you go varies on your development environment.

Tom Manza
  • 1
  • 1