Mxolisi Veco wrote:
What can I add to the statement such that I will not get the uncheck warning ?
There's no clean solution, you have to suppress the warning, as David has said.
The reason is that at runtime, you have no information on the type parameters, so no magic will save you. You could improve this somewhat by turning y into HashMap<Integer, String> though, so you'll be type-safe at least from that point on (if y really is that type - it is, in your case, but if it's something you've restored from serialised form, or got from some other piece of code you have no control over, and the Object points to a HashMap where the key and the value are not Integer and String, you'll run into ClassCastExceptions, or, even worse, hard to find bugs - Map.get, containsKey, containsValue take Object as parameter so no cast/typecheck will be performed even at runtime, get will just return null, contains* false).
I tried but the warning were still there. So suppressing the warning does the job.
The chance of getting a ClassCastException is zero because I build the part that returns an Object that contains a HashMap<Integer,String>. The problem is I can not return the HashMap<Integer,String> I can return Object though. So I put the HashMap<Integer,String> in the object as a result.
The problem is solved now thanks.
2. I need something that can carry a HashMap in the event of a succesful search or an exception in the event of a failure.
The only thing that I know tha can carry any of these is an Object.
wrap the call
This is what I do currently
From what I understand, I will still get the results from the server as an Object and I will be forced to cast the results which will generate a warning. So suppressing the warning seems to be the only way to work around this without complicating the source code.
What is it that I wrote that makes you think it does not?
The server is running on a different machine, if a throw the exception on the server side, then the client will never know that something went wrong. So I return the Exception or the HashMap to the calling client. Then the client checks the results that they contain the HashMap. If the results are not a HashMap, then they are an exception.
Mxolisi Veco wrote:What is it that I wrote that makes you think it does not?
Because you said:
2. Check that the result are of type HashMap
if results are of type HashMap
cast the results to a HashMap
throw an exception.
Throwing an exception is not the same as returning an exception. If you're *returning* an exception, you're correct--but that would defeat the purpose of both exceptions, and type safety.
My original suggestion still stands: either return the HashMap, or throw an exception. Keep the signature as a HashMap and keep the code that calls the method substantially cleaner.