I got this, too. It's basically the same as the renewal notices I get from them, so it appears legit, but the expiration date made me double-take.
Thuktun
@Thuktun
Best posts made by Thuktun
-
RE: Already Expired
Latest posts made by Thuktun
-
RE: The unconditional checkfile exception condition idiom
@Mason Wheeler said:
Java still doesn't have any form of closures or nested procedures, so this particular form of abuse would probably not be possible in Java.
Java's had anonymous inner classes forever. Although the syntax is painful and they require an interface or class to extend to use them effectively, these can be used in much the same way as closures.
Many of us who still use Java (or at least the JVM) and want to use features like this have moved on to Groovy or Scala, though.
-
RE: The unconditional checkfile exception condition idiom
@airdrik said:
Except that's not how exception stack traces work. The exception doesn't need to traverse back up to fill it in, it gets filled in based on the call stack that constructed the exception.Except that there is no stack trace because the exception didn't get thrown up the stack (or the stack trace only has one item which is the point where the exception was created which is no more helpful than the logged error message).
-
RE: Yesterday at the Outback
Exactly. I still feel like I'm in my twenties. Society expects me to act sensible and middle-aged, but I don't want to.
I hope I'm lucky enough to be around and feel the same when when I'm in my 70s!
-
RE: The unconditional checkfile exception condition idiom
@TheRider said:
That's not as much of a WTF as you suggest. If that's the logging framework you're stuck with using and you really need it to log a stack trace, then that's how you'd need to do it.WTF 3: Creating an exception for the purpose of logging it, not throwing it. Well, the Logger doesn't have an error-method without an exception-parameter. Therefore, one must be created, obviously!
-
RE: General flags
@Mason Wheeler said:
Um, no. Java 'static' on a field means class-level rather than instance-level. Final is probably what you're thinking of.OK, my Java# is a bit rusty, but doesn't "static" mean "const" in this context?
-
RE: General flags
@Jaime said:
... yeah, they put booleans coded as numbers coded as chars in a char array. Essentially, they made true=49 and false=48. I'm pretty sure the zero and one in the comment are array indexes, not values, so normal would be both flags off. The whole thing does nothing but double-obfuscate the information it is storing.
Yes. True/false are represented by '0'/'1' characters and the 0/1 in the comments are positions into the array. Those "flags" would properly be individual Boolean fields...if it was at all necessary. If anything looked at those flags in the past, nothing does now; they're currently write-only.
The logging in this application is a mix of hand-rolled filesystem logging, inserts into a database table with backup rolling of those to the filesystem, and immediate emails. However, the criteria for determining which one of these methods is used is practically Byzantine. Filesystem log entries don't contain a timestamp and often include supporting information (like a stack trace) for an error message sent through one of the other channels, so there's no way to tie anything together except circumstantially.
All of this conspires to make the logging pretty much useless if you're trying to do detailed troubleshooting. It's really only been useful in its original state as a volume indicator: when error volumes are unusually high, something is going wrong.
And by "unusually high", I mean that error emails go from 100-1000s per day to almost half a million. That particular condition occurs when a user enters a trans-ASCII character on the website.
-
RE: Yet another Representative Line
@morbiuswilters said:
consts are static in Java, but it needs the final keyword to be truly constant.
The static final modifiers in Java do not imply a constant for objects unless the object is immutable. Static final arrays are amusingly non-constant. -
RE: General flags
(The missing close-brackets are the compose form's fault, for whatever reason.)
-
General flags
In our continuing struggle supporting an existing application our employer acquired, we continually run into bizarre things. There's just so much wrong with this:
/** * General flags. This helps to keep track of some problems and statuses of the program: * 0 - Cannot write to log, storing log into file. * 1 - Cannot write to backup file, losing log records. */ private static char[ ] flags = new char[ ] { '0', '0' };
mod: fixéd les brackettes –dh