Stephan van Hulst wrote:If your method call can succeed or fail, there are two acceptable options:
Return a boolean value indicating success. This is appropriate if failure of the method call is a normal occurrence and can happen regularly. Throw an exception. This is almost always the more appropriate option, because failure is usually an exceptional situation.
Why would an SQL query fail, unless something exceptional happened? So throwing an exception is probably the way to go. Now, you have two ways of throwing the exception:
Paul Clapham wrote:Can you burp the alphabet?
Michael Angstadt wrote:As a software developer, it's important to make your code readable so that other developers (as well as your future self) can understand what you've written. However, complex regular expressions are notoriously difficult to read. Do you have any tips for improving the readability of regular expressions? Thank you!
Henry Wong wrote:
Ryan McGuire wrote:
Hee Hee. Only a fellow trainer would understand the significant of those numbers....
Too bad there are very little reasons to friend a trainer that you will never battle, raid, or trade with... or I would send an invite.
(1/14 + 2/3) * 5/32 = 0.738095238095
Ryan McGuire wrote:
If you need to report out a fraction at the end of a calculation, could you just do the whole calculation in fractions instead of using doubles at all?
Randall Twede wrote:going from fraction to decimal is easy, you just divide. to go from decimal to fraction is a bit harder.
the algorithm i came up with for that is you multiply and if the result is an integer, that is the numerator and what you were dividing by is the denominator.
you loop through integers to find the denominator.
for example 1/4 = .25
you multiply .25 X 2 = .5 = no
.25 X 3 = .75 = no
.25 X 4 = 1 = yes
so .25 = 1/4
this works except for repeating numbers like .333333333333333333333
is there a way to make my algorithm work?
Tim Cooke wrote:Saying 'buzzwords' in an interview is only useful if it comes across that you clearly know what they mean. Consider putting together some programming scenarios and examples that make use of these constructs and concepts so that you can have a good discussion with your interviewer and show that you understand them in the right context.
For example, what is an immutable object? How might you construct one in Java? Why might you want an immutable object?
For me a good interview is a discussion, rather than a pop quiz.