[ale] found a bug in an open source API: It 'Broke' under linux.

[Michael Trausch]

Any good editor (*cough*emacs*cough*) will properly indent and clue the
human into the error. Its all about the text editor. ;)

--
Sent from my phone... a G2 running CM7 nightlies!
On Feb 12, 2011 5:11 PM, "Tim Watts" <tim at cliftonfarm.org> wrote:
> [ pardon me for I'm butting in ]
>
> You're right: to the compiler it's just style. But I look at them as
> cheap insurance against future bugs.
>
> // The code in Feb 2011:
> if (somethingIsTrue())
> doASimpleTask()
> else
> doTheAlternateTask()
>
> // The code in Feb 2012:
> if (somethingIsTrue())
> doASimpleTask();
> else
> doTheAlternateTask();
> doTheWorkAroundToo();
>
> Of course, this is broke and you may very well have caught it. But
> enclosing it in {} in the first place would have avoided the need to
> even think about it. About the only time I'll omit braces is with
> conditionals that are one-liners (and sometimes not even then):
>
> if (log.isDebugEnabled()) log.debug("now i'm opening the pickle jar.");
>
>
> On Sat, 2011-02-12 at 16:06 -0500, Joshua wrote:
>> James,
>>
>> I put the {} around the block, (which helps to guard against certain
>> bugs). the {} make the code easier to read, but I do not know that with
>> one line of code they prevent any bugs.
>>
>> from what I read, and the discussions I had on iirc, a dangling else is
>> more of a grammatical (readability) thing, from a human perspective, the
>> compiler /interpreter will take care of any ambiguity with if/else
>> blocks, as far as I can tell. The else attaches to the nearest if
>> block. I can see the issue from a psuedocode perspective, where the
>> grammatical ambiguity can cause problems when actually implementing the
>> code, but one the code is written it is the placement of the } from
>> preceding if statements that determine which 'if' the 'else' will attach
to.
>>
>> or am I missing something?
>>
>>
>>
>> Maybe that is all the dangling else is: a semantics things.
>>
>>
>> James Sumners wrote:
>> > My only suggestion would be to fix your dangling else block --
>> > http://pastebin.com/pTzUQzjJ
>> >
>> > On Sat, Feb 12, 2011 at 2:53 PM, Joshua <jrtroberts at gmail.com> wrote:
>> >
>> >> I am working with an API for currency conversion from
>> >>
http://www.thomasknierim.com/index.php?s=currencyconverter&Submit=Search
>> >> <
http://www.thomasknierim.com/index.php?s=currencyconverter&Submit=Search>
>> >>
>> >> It is all written is Java.
>> >>
>> >> The initCacheFile() method worked fine under windows, but it broke
>> >> under linux.
>> >>
>> >> The original code grabbed the path to the java temp directory and then
>> >> concatenated a file name onto the end of it. I do not know what it
>> >> produces under windows, but my suspicion is that windows is something
>> >> like </driveletter:\pathtotemp\/> with the trailing '\' included.
>> >>
>> >> Under linux the call to return the temp directory returns '/tmp' and
>> >> then the concatenating of '/filename/' creates a file named
>> >> /tmp/filename/ instead of /tmp//filename/ so the application was
trying
>> >> to write to / where it did not have permissions. So I had to write a
>> >> fix. Still not sure the fix is this best.
>> >>
>> >>
>> >> Maybe someone can look at the code I wrote and let me know.
>> >>
>> >> http://pastebin.com/vsC6vZRU
>> >>
>> >> The old code is commented out.
>> >>
>> >> Joshua Roberts
>> >>
>> >
>> >
>> >
>>
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20110212/92ed6b40/attachment-0001.html