Paul Clapham

Jack Tauson wrote:Should I do it like this (encode \ as %5C):

%5CABC10PCS_2015AA%5C

Well, yes and no. You should just be URL-encoding all of the parameter values of your URL, is what you should be doing. Not asking whether specific characters should be encoded.

Looks like you got your problem solved, then? I will mark the thread as "resolved" but if it turns out you want more discussion, then sure, carry on posting here.

Wikipedia has an article about it: Double-ended queue, in which it is claimed that it's pronounced "deck". It has a citation so it must be right, right?

I wouldn't pronounce it that way but clearly I don't get out enough.

Hmmm... there's a class java.util.JarFile which looks like it might support that kind of thing. But then you would have to know that your resources were in a JAR and you'd have to know where the JAR was located with respect to your code. I suppose treating the JAR as a resource might work for locating it, but writing code to extract the real resources from the JAR strikes me as not being something you want to do. Sort of an ugly workaround, really. But check it out and see if it doesn't stink too badly for your needs.

No, resources work perfectly well in a JAR. Just don't treat a resource as a File, because it isn't one.

Instead, use the getResourceAsStream() method and you'll have an InputStream from which you can read the contents of the resource.

Campbell Ritchie wrote:Round here it would be e′noom with a short oo as in book. And the longer word would be e-nUm-eration with the U a diphthong.

I pronounce it (in my mind) as e-noom to rhyme with "doom". Just the first syllable of "enumeration".

Original code:

aaaaa bbbbb ccccc

Deleting the middle line:

aaaaa ccccc

Blanking out the middle line:

aaaaa ccccc

John Ellee Robado wrote:I need help pleasee

I suggest paying closer attention to the answers you already received. They asked for more information but all you provided was some cryptic comment about "codes" at the top of the image you posted. I don't understand what you mean by "codes", all I see is a calendar sort of thing in the image. Probably nobody else understands "codes" either.

So. Describe what you did, tell us what happened, tell us what you expected, tell us about things like error messages. The more information the better.

Tim Holloway wrote:In HTTP(S), 500-level response codes should not be used for things like invalid data. A 500 is supposed to indicate that an app function failed unexpectedly - a bug or a problem with request routing.

And with respect to your question, this means that your code should not throw an unchecked exception. Not unless you plan to catch it at a higher level and deal with it appropriately, that is. In which case you might just as well throw a checked exception.

Michael Farragher wrote:2). Does it matter about the thread safety of the type you're using ? I've read that any type will do.

The object only exists to support locking and synchronization (at least, that's all you should be using it for). So you aren't going to be calling any of its methods. And yeah, any type will do but if you don't use Object then future readers of your code are going to have to stop and ask why you used some other type. You shouldn't make them do that.

So you can create a Map and fill it with up to 10 entries using one line of code, instead of the 11 lines of code it used to take. You might ask "Why 10 and not 20 variables?" Who knows? Maybe they surveyed a collection of random Java code to find out how often people pre-filled a Map with X entries, or maybe they just picked a reasonable-sounding number.

Kirk James wrote:Thank you for your opinion, so, about the scenario I showed previously, do you think that a checked exception could be a better solution?

The general rule is: If you expect that something in your application will be able to do something useful when the exception is thrown, then it should be a checked exception. Whereas if you don't expect anything in the application will be able to deal with the exception, and therefore the application should end instead, then it should be unchecked. If it's a web app then yes, generally a checked exception allows your application to notify the client in application-specific terms and return a 404, and an unchecked exception allows your application to automatically do nothing about it and allow the server to return a 500.

Note that "something useful" could even include "log the exception and continue with no other action". Or even "continue with no other action". That all depends on the design of the application.

An interesting question... To tell the truth I have never ever spoken that term, so my answer to that question should be something like "undefined" or "null". However if I were to speak the term I would pronounce it with the first syllable like the first syllable of "variable". I think.

Stephan van Hulst wrote:I agree that it looks like a poor tutorial, but on the other hand I also believe Maven should be standard knowledge for any Java programmer who is at the level of using connection pools.

IF Yosuf Ibrahim doesn't have to rush to finish this task, now is as good a time as any to learn Maven.

I suppose that's right too. When I installed a connection pool (in March 2019) I chose c3p0, which didn't have any external dependencies and which documented what jar files needed to go in your classpath. So I didn't need Maven, which was fortunate because I've never used it. But when I upgraded my version of Apache POI (in March 2020) there were a lot of external dependencies which I had to track down the hard way, and knowing Maven would have been useful then.

(In other words: you can see my bias regarding Maven.)

Wouldn't a transfer between two accounts require two queries, one for each account?