We Keep Coding

In case of an exception in webservice is the control returned to to UI with error?

I have a UI page developed using angular js and make a rest webservice call. If an exception is thrown by webservice will the control be returned to the UI with the error?

yes, it will be returned to the client. This is true even if the server timesouts.
But it might not be in a format as you expected. For example, you might have sent a json request and expecting a json response. But you might get an html response if the server has setup a simple html handler for error code. In this case your response parsing will fail. One common example is the authentication failure, which simply redirects you to html login page in many services.
So before parsing the result, check the status code. Check the service rest api docs and study the error handling semantics. Then parse the error accordingly.

Proper Http status codes for uploading files on rest end point

We are developing an application that allows a user to upload file on rest end point.
Could someone please guide if it is correct to send 400 error code for the failure of following validation scenario:
1) The Length of file name exceeds permissible limit.
2) File name contains special characters
3) Uploaded file was empty
4) The System failed to read the uploaded file from disk.
Regards,
Tarun

The Length of file name exceeds permissible limit.
I think the 400 is not an appropriate because syntax of the request is correct in this case. The 422 Unprocessable Entity is better in this case.
File name contains special characters
Illegal characters mean the syntax is broken. So 400 Bad Request is a proper response in this case. Someone may claim that a definition of illegal characters is needed so the server may authoritatively send 400.
Uploaded file was empty
I think it is not an error because an empty file is a legal file.
The System failed to read the uploaded file from disk.
Does the system mean the server? Then the server should return a 5xx response because it is not a client failure. In case of general read error the server should return 500.
EDIT:
Uploaded file was empty.
When application semantic forbids an empty file the 400 or 422 appropriate. More details about them is at 400 vs 422 response to POST of data

4xx statuses are for client-side errors, 5xx are for server-side errors. So, generally you need 4xx codes for your cases 1) to 3), while 4) should be a 5xx error.
Let’s first say that for your case 4), a simple HTTP 500 seems appropriate. If you want to indicate that the client could try again later, HTTP 503 would be more suitable.
Now for 1) to 3): According to RFC 2616, HTTP 400 indicates syntax errors; this would usually be protocoll errors, e.g. invalid headers. Semantical or payload errors aren’t really defined in this generic RFC, however, (as Zaboj mentions) WebDAV offers HTTP 422, which seems suitable, though it’s not really meant for generic HTTP.
In the end, it doesn’t really matter which particular codes you send. If your upload fails with HTTP 400 or 422, in either case the client will perform some error routine (e.g. show or log the error message).
The important thing to know is that some codes can trigger client behaviour (e.g. HTTP 401 combined with certain headers can trigger an authentication dialog in a browser), and you should be aware of these side effects.
In my opinion, it is much more important to send a useful error description in the response body to help the client fix their problem, than finding the “perfect” HTTP status code. I know that REST zealots will disagree, but none of them will be able to give you the right HTTP status code for every situation.
That said, if you want to issue fine-grained error codes/messages for automated processing, you can introduce custom HTTP header fields, e.g.
X-MyApp-Error-Code: 2.1.6
X-MyApp-Error-Message: The uploaded file is empty
Then you would provide a documentation and/or SDK which reveals all possible error code values for X-MyApp-Error-Code to your API consumers.

Rest error codes/ success code

I am working on REST project using jersey. On success I am returning 200 code along with the json response for particular request. I know there are may different classifications of error codes, like server error which start with 500, client error which start with 400 etc. My question is suppose we are subtracting some value in database for example count, for example count in database is 5 and request comes to subtract 3, it is valid and i will send request but my business rule states that count cannot be less than zero, so if request comes 6, i cannot subtract that , so in that case should i actually send status code as 200 and send error information is json respose {"errorCode" : "1","errorMessage":""} so i should send different HTTP status code like 5## that there is server problem or 4## saying bad request.
Can anyone please suggest me good (in the sense which is restful and follow all standars) REST project on github which I can refer.

If any error occurs during request processing you should never send a 2XX status code. Why? Because 2XX indicates successful processing which in this particular situation did not happen.
When you send a value to be subtracted from another value in DB and the assumption is that the result can't be lower than 0 you should reply with 409 Conflict HTTP status code and clarification in a response body stating e.g.:
The request can't be completed since the result value will be lower than 0.
It would be 400 Bad Request if null e.g. is sent instead of a number.

In the particular use case, you mentioned, you should return 400 as status code (bad request). errorCode in the json is your business domain, so you can use what you want ( Also, take a look at JSend standard for sending the http "error status" in the response https://labs.omniti.com/labs/jsend )

You're exactly right: you should send an HTTP "400" for a client error, a "500" for a server error, etc; along with a specific error message.
You may or may not want more granular HTTP status codes (for example, "403" for client authentication failed, otherwise "400" for other client-related errors).
Are are two good lists you can use for guidance:
Common MS-Azure REST Error Codes
HTTP Status Codes
NOTE:
There is no "standard" per se. The two links I gave above are useful "examples". The "official" IETF RFC for HTTP 1.1 Error codes is RFC 2616:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

URL submit with "get" mode, response"400" error

when I raise request with follow url:
myip/searchapp/genericSearch/genericSearchInit.html?securityName=&identifierType=3&identifierCode=test&vendor=4&startDate=10%252F1%252F2013&priceType=&currency=&endDate=&exchange=
I got 400 error:
Failed to load resource: the server responded with a status of 400 (Bad Request)
But when I give some values such as
myip/searchapp/genericSearch/genericSearchInit.html?securityName=&identifierType=3&identifierCode=test&vendor=4&startDate=10%252F1%252F2013&priceType=1&currency=1&endDate=1&exchange=1
and it become legal url.
can any guy tell me why? and how can I deal with it?

Try leaving out those last parts completely if you don't need them:
myip/searchapp/genericSearch/genericSearchInit.html?securityName=&identifierType=3&identifierCode=test&vendor=4&startDate=10%252F1%252F2013
it must be that whatever page you are calling is using those variables to redirect to different pages. It seems that the page breaks when an empty string is sent in.
That page is probably using key_exists() checks, which would return false if the query didn't have it at all but true if you sent an empty string, and not an additional empty() checks, which would return false either way.
If that page is yours, then you could probably adjust it so that the it is valid to send empty data. If it isn't yours then it is just the way that specific page is working, there really isn't anything else to understand.
It is a bug, report it to whoever is in charge of the page.

The only difference that I can tell in those two urls is
priceType=&currency=&endDate=&exchange=
versus
priceType=1&currency=1&endDate=1&exchange=1
It seems the server doesn't like missing data and therefore sends 400 Bad Request. You need to figure out what your service expects and send that.

How to check if there was the execution of the servlet is Exception free

Hi I am fairly new to Java Servlets. I want to ensure that the execution on the server side code is exception free i.e I want to check if there was any exception thrown on the server code. How can I determine that using the response that I get?
Thank you

Since, a Servlet executes server-side it's the server-side code that determines whether the client should be made aware of an exception or not. A client wouldn't come to know of it automatically unless the exception is not handled (within the servlet code) and no error pages were set for the web application (both of which aren't recommended).
Ideally, a client should never be made aware of the exact exception. Instead, the client should just receive a proper error message as to why the current request couldn't get processed successfully.
Error details should be shared on need to know basis. For example, if the input validation fails it makes sense to include the name of the field that was invalid in your error message. It isn't proper to show a NumberFormatException instead (say, because the client entered an age that was non-numeric).
EDIT:
There's no one single right approach here. There are various methods you can adopt based on how much descriptive your web application wants to be about the error to your client.
If you just require to let the client know that an error occurred with a brief error description you can use sendError() (which behind the scenes would automatically set the HTTP status header to an error code like 400 Bad Request below)
if (request.getParameter("id") == null)
response.sendError(response.SC_BAD_REQUEST, "ID parameter missing");
Other approaches include configuring <error-pages> in your web.xml for different error codes or exceptions. The container would take care of automatically forwarding to the .jsp files configured below.
<error-page>
<error-code>404</error-code>
<location>/error404.jsp</location>
</error-page>
<error-page>
<exception-type>java.lang.Exception</error-code>
<location>/errorPage.jsp</location>
</error-page>
The JSPs need to have their isErrorPage attribute set to true to receive an implicit exception object to get more information about the exception. For example, exception.getMessage() could be used (in some cases) to generate the error message to be shown to the user.
The client side
The client doesn't need to do anything special (like a getError()) to receive the error. The client would still be receiving HTML that gets rendered by the browser just like if the request had succeeded but since it didn't, the client would receive the error message formatted as HTML (can even view > source it).
The HTML sent depends on whether you used sendError() (which would send the standard error response from your web server like Tomcat) or your own configured <error-page> JSPs in which case you have complete control over your HTML error template.

If you get the content from the servlet, there where not unhandled exceptions. If you want to get info of handled exceptions, log them in their catch clause.

Use log4j to catch your exception (using try catch block) but if this is some kind of homework you are working then this might be one way you could check based on the http return code. you can use jquery http://jquery.com/. Here is sample code for 404 error.
Also this page has all the http error code and what they mean.
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>
<script>
$(function() {
var urlPath = "some_url";
$.ajax(urlPath,
{
statusCode: {
404: function() {
alert('page not found');
}
}
});
});
</script>