• (disco) in reply to Yamikuronue

    *cough* The Java version is not the same as the JDK version, because Sun and Oracle are assholes.

    JDK 1.2 through 1.5[1] actually are Java 2, although I'm skipping a bunch of nuance including that part of that version name was retroactive.

    [1] Even though JDK 1.5 is for Java 5. Maybe someone wrote something wrong on Wikipedia. I'm not going to get into J2[SME]E, either.

  • (disco) in reply to FrostCat

    Well sure, but he said "Java 2.5", that was nice and ambiguous. I guess he could have meant J2SE 5, but that basically equates to Java 1.5 anyway.

  • (disco) in reply to Yamikuronue
    Yamikuronue:
    Well sure, but he said "Java 2.5", that was nice and ambiguous.

    Yeah, I didn't mean to sound like i disagreed with that.

    Java/JDK version numbering is approximately as obnoxious as Windows numbering.

  • (disco) in reply to FrostCat
    FrostCat:
    as obnoxious as Windows numbering
    Depends what lineage you're talking about; for the most part, the NT line has been fairly consistent. OK, it got out of sync with 7, 8, and 8.1 all being 6.numbers underneath, but with 10 it's all back in sync.
  • (disco)

    JdbcTemplate has been part of Spring since (at least) 2.x1.0.0. Java's version has nothing to do with it.

  • (disco) in reply to RaceProUK
    RaceProUK:
    Depends what lineage you're talking about; for the most part, the NT line has been fairly consistent. OK, it got out of sync with 7, 8, and 8.1 all being 6.numbers underneath, but with 10 it's all back in sync.

    Yes. That is pretty analogous to the way the JDK and Java versions aren't the same.

  • (disco)

    Bradley seems a little too idealistic for somebody who's "seen this antipattern many times before".

    This is pretty common shit you have to deal with in the enterprise software world. Go work for a startup if you want to refactor everything on a weekly basis.

  • (disco) in reply to sloosecannon
    sloosecannon:
    Throwing Exception is probably the stupidest anti-pattern possible though

    It's been a while since I've done Java, but I remember getting to that point pretty fast. You have some method that can throw 5 types of exceptions and calls 3 methods that each have 5 of their own types of exceptions they can throw, so your declaration is one line of relevant material and 20 lines listing which kinds of exceptions the thing throws.

    Change one of the underlying methods to add a 6th exception type, and you have to find all the uses of that thing to update them--which of course we know is a problem in this organization.

    / Couldn't the compiler theoretically keep track of which exceptions get thrown/caught and how they bubble up? Could treat it as a warning or error, or just outright ignore it like these guys would.

  • (disco) in reply to mruhlin

    Yet another proof that C#'s way of doing exceptions is better. All hail the high king of languages!

  • (disco) in reply to mruhlin
    mruhlin:
    Couldn't the compiler theoretically keep track of which exceptions get thrown/caught and how they bubble up?

    It can track what is thrown, but not what should be thrown.

  • (disco) in reply to Magus
    Magus:
    Yet another proof that C#'s way of doing exceptions is better.

    If you believe that, just make all your exceptions inherit from RuntimeException. (The Error subclasses are for shit you can't really do anything about in code, like the JVM throwing a major wobbly.)

  • (disco) in reply to dkf

    The Java way would be better if people only declared checked exceptions when strictly necessary; unfortunately, too many people go overboard with them

  • (disco) in reply to PWolff
    PWolff:
    hard drive space tends to get clogged with code issue log files (though it takes time).

    What are you talking about. I have worked on systems that were going very well, and there were over 100,000 items recorded in the tracking system with ZERO performance impact or issues with "hard drive space". With disk space being in the pennies per GB range for even most server environments, this should NEVER be an issue.

  • (disco) in reply to DocMonster
    DocMonster:
    That's assuming that it ever gets addressed. In my experience most of the time it doesn't matter if you track the issues or not, it will never ever be scheduled for "review and remediation" because whoever decides that sees no value in fixing what "already works", no matter how shitty/busted it really is.

    Depends, if the developer do their due diligence and establish proper links to every bog that can be traced back to the "bad code" along with isolating the incremental work that is cause by the "bad code", the evidence can become quite obvious.

    Once this happens, raising the issue high enough with the dollars being quantified WILL get the attention of upper management.

  • (disco) in reply to Maciejasjmj
    Maciejasjmj:
    sloosecannon:
    Throwing Exception is probably the stupidest anti-pattern possible though......

    But you'll find this kind of stupid shit in every codebase - sometimes it will be the small things like throwing an Exception

    Hi, my name is @izzion and I wrote an extension for a LOB application that threw Exception for pretty much any problem (though not all the way out to the end user).

    Oh, right, the Programmer's Anonymous meeting is :arrows: that way

  • (disco) in reply to TheCPUWizard
    TheCPUWizard:
    establish proper links to every bog

    I don't think any link to Swampy could ever be "proper."

  • (disco) in reply to TheCPUWizard
    TheCPUWizard:
    proper links to every bog
    Are the toilets really that difficult to find normally?
  • (disco) in reply to izzion
    izzion:
    Oh, right, the Programmer's Anonymous meeting is that way

    Worth an extra like.

    Why doesn't the topic exist here already?

  • (disco) in reply to PWolff

    Maybe because Rock Bottom for a programmer is when Paula Bean puts you in a ditch for getting caught fiddling with the code at a shady online casino?

  • (disco) in reply to EatenByAGrue
    EatenByAGrue:
    Translation out of management-speak: 1. If you make a change and something goes wrong, it's your fault, because you didn't do exactly as you were told. 2. If you don't make a change and something goes wrong, it's your fault, because you weren't proactive and independent.

    This has been my experience too. However, many people take the wrong lesson from it. If you look at the decision matrix that those two facts form, you'll see that getting in trouble does not depend on not doing as you're told, it depends on things going wrong. The correct behavior (at least the correct game-theoretic behavior) under these rules is to completely ignore management and do what it takes to make things not go wrong.

  • (disco) in reply to Jaime
    Jaime:
    do what it takes to make things not go wrong.

    I've learned at school this isn't feasible. So do what it takes to make people believe it's not your fault.

  • (disco) in reply to jnareb
    jnareb:
    > And yes, screwing around at will with functions you don't know and for which there are no unit tests just to make them look nicer is just asking for time bombs. BTDT.

    Actually IIUC if those specific error classes inherit from Error, then all the existing code that catches generic Errors thrown would still work, as per inheritance.

    On the other hand thing how much fragile code one would have to write without this change.

    Every so often I spot someone trying to catch Error in Java. I wonder, what do they think they're going to do with it? (The usual answer is "Log the error and try again" which doesn't help you much when the disk disappears or you encounter a corrupted opcode.)

  • (disco) in reply to foxyshadis
    foxyshadis:
    Every so often I spot someone trying to catch Error in Java
    I'd be tempted to bring this baby out: [image]
  • (disco) in reply to TheCPUWizard

    Then each issue gets ignored for years by management because it's not a new feature.

  • (disco) in reply to foxyshadis

    Well, some errors you can recover from rather easily (missing/badly versioned linkages), and in other cases it might be worth it to at least try and show a nice looking error message instead of Windows Error Reporting.

    "Try again" might be an option with OOM, but I wouldn't count on it.

  • (disco) in reply to RaceProUK

    Emmm... I still think that in Java you throw Exception but catch Throwable instead so you can also catch Error.

    So that your function will look unbreakable

  • (disco) in reply to Maciejasjmj
    Maciejasjmj:
    some errors you can recover from rather easily (missing/badly versioned linkages)

    Just what exactly do you plan to do about it? When those sorts of things go wrong, you've typically got no meaningful recovery plan beyond redeploying the application. (Assuming you're not doing dynamic loading of code at that point; you might recover if you are. But probably won't in a way that anyone really wants.)

    Maciejasjmj:
    show a nice looking error message

    That (plus logging the problem, but that's just “nice” for the developers/deployers) is the only good reason for doing it I can think of.

  • (disco) in reply to powerlord

    I think you'll find that the interface in question was http://docs.spring.io/spring/docs/2.5.x/api/org/springframework/jdbc/core/JdbcOperations.html

    Oh, look at that – version 2.5. You know, the article didn't say Java version 2.5.

  • (disco) in reply to PWolff

    What that takes is avoiding doing anything that might leave your fingerprints on anything that might go wrong.

  • (disco) in reply to Buddy

    Is that anything like http://docs.spring.io/spring-framework/docs/1.0.0/api/org/springframework/jdbc/core/JdbcOperations.html ?

  • (disco) in reply to flukus

    I've worked in alternate dimensions where "refactor" meant "add new features". I got there after Management learned that refactoring was important but didn't want developers wasting time on something else when they could instead be adding the latest shiny thing. Clearly the solution was to redefine the word.

  • (disco) in reply to RaceProUK

    They're easy enough to find, but you've got to make sure you get exclusive use of the stall first.

  • (disco) in reply to Watson

    I didn't say it wasn't in spring before version 2.5.

  • (disco) in reply to cheong
    cheong:
    So that your function will look unbreakable

    Filed under: http://thedailywtf.com/articles/Exceptionally-Hard-to-Swallow

  • (disco) in reply to Watson
    Watson:
    What that takes is avoiding doing anything that might leave your fingerprints on anything that might go wrong.

    This runs afoul of rule #2:

    If you don't make a change and something goes wrong, it's your fault, because you weren't proactive and independent.
    I don't see why you would believe you would get in trouble for legitimately not making a change, yet get away with it if it only appeared you didn't make a change.
  • (disco) in reply to mruhlin
    mruhlin:
    sloosecannon:
    Throwing Exception is probably the stupidest anti-pattern possible though

    It's been a while since I've done Java, but I remember getting to that point pretty fast. You have some method that can throw 5 types of exceptions and calls 3 methods that each have 5 of their own types of exceptions they can throw, so your declaration is one line of relevant material and 20 lines listing which kinds of exceptions the thing throws.

    Change one of the underlying methods to add a 6th exception type, and you have to find all the uses of that thing to update them--which of course we know is a problem in this organization.

    / Couldn't the compiler theoretically keep track of which exceptions get thrown/caught and how they bubble up? Could treat it as a warning or error, or just outright ignore it like these guys would.

    You can have it throw a supertype of each exception. Or just let the IDE do all the work (IntelliJ does, I'm fairly sure Eclipse/Netbeans do too) With multi-catch blocks you don't have that many problems...

  • (disco) in reply to Michael_Mahn

    Both are a bit.

    I have a similar conundrum with a legacy code base where it is hard to add significant unit tests. Though tools like VCS, testing environments, etc keep things sane enough. I still spend a lot of time refactoring. Otherwise the technical debt would be fatal. In that situation you don't let people refactor unless you trust them though.

  • (disco) in reply to boomzilla
    boomzilla:
    Remember: the objection was from a guy who freaked out about removing unused imports.

    Which makes this statement

    Only the instant messenger’s lack of emoji support saved Bradley’s job.

    the true :wtf: yeah yeah yeah. Find a new job first before burning bridges...

  • (disco)

    Bill looked upon Java, and saw a confusion of new language concepts. "This new-fangled stuff is a evil," he opined.

    Recoiling in horror, he took a deep breath and declared, "Let there be C."

    And there was C. And Bill saw the C and saw that it was good." And may C reign in Bill's code base forever and ever.

  • (disco)

    So... is TRWTF the lack of logging, unit testing, and integration testing as a change management backstop being used as an excuse for Bill's self-serving obstructionist policies, or is it Bradley's intransigence in the face of those policies? You make the call!

    Though it isn't as if we haven't covered this ground before. I say we should award Bill and Bradley a joint WTF for their (un)cooperative effort. What says the Academy?

  • (disco) in reply to Magus

    You can still catch any sub-type of Exception. If a method throws generic Exception but you want to specifically deal with IOException you can catch IOException only and only that will be dealt with. You only need a second catch block that catches exception (or method must also throw exception again).

    The better idea however is to get rid of this checked exception BS and only extend from RuntimeException which is unchecked.

  • (disco) in reply to beginner_
    beginner_:
    The better idea however is to get rid of this checked exception BS and only extend from RuntimeException which is unchecked.

    But then you get the problem of people not actually trying to handle exceptional cases at all (so a butterfly's sneeze kills the program), or handling everything with the moral equivalent of ON ERROR GOTO NEXT.

  • (disco) in reply to beginner_
    beginner_:
    The better idea however is to get rid of this checked exception BS and only extend from RuntimeException which is unchecked.

    O.o

    No, you should throw Exception subclasses when appropriate and throw RuntimeExceptions when they're appropriate

  • (disco) in reply to sloosecannon
    sloosecannon:
    RuntimeExceptions when they're appropriate

    which IIRC is, according to the official Java documentation that i can't he tailed to look up at the moment, only appropriate if one of following conditions occur:

    1. You are writing core Java while working for Oracle, and even then only if something absolutely unrecoverable has happened.
  • (disco) in reply to accalia

    https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html seems to imply that it's ok if it's unrecoverable in general.

    If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.

    But using only RuntimeExceptions is crazy and a terrible idea. Plus it's against the "standard"...

    Relevant quote:

    Generally speaking, do not throw a RuntimeException or create a subclass of RuntimeException simply because you don't want to be bothered with specifying the exceptions your methods can throw.

  • (disco) in reply to sloosecannon

    Strictly, errors are for unrecoverables, runtimeexceptions are for unlikely-to-want-to-recover-froms, and other exceptions are for you-ought-to-think-about-handling-this.

  • (disco) in reply to sloosecannon
    sloosecannon:
    seems to imply that it's ok if it's unrecoverable in general.

    which means that it's only okay in java core (or possibly when interfacing with custom hardware)

    anything that involves remote server communications or internal calculations, or basically anything that is not local hardware can be recovered from.... in theory.

  • (disco) in reply to dkf

    Yeah.

    Using a good IDE and modern Java version (1.7+) a lot of the exception problems are pretty irrelevant. At least if you've done the sub-exceptions right. Multi-catch and catching supertypes cut down on your issues.

    Example: Not good:

    public List<String> readFile() throws IOException, FileNotFoundException, ReadException, OtherIOException
{
   //Do things
}

[...]
try{
   readFile()
}
catch(FileNotFoundException e)
{
//stuff
}
catch(ReadException e)
{
//stuff
}
catch(OtherIOException e)
{
//stuff
}
catch(IOException e)
{
//stuff
}

    Good:

    public List<String> readFile() throws IOException
{
   //Do things
}

[...]
try{
   readFile()
}
catch(FileNotFoundException e)
{
  //Tell the user the file doesn't exist
}
catch(ReadException | OtherIOException e)
{
   //An error occured while reading
}
catch(IOException e)
{
   //An IOException happened somewhere else
}

    Or, even shorter...

    public List<String> readFile() throws IOException
{
   //Do things
}

[...]
try{
   readFile()
}
catch(IOException e)
{
   //An error occured while reading
}
  • (disco) in reply to accalia
    accalia:
    sloosecannon:
    seems to imply that it's ok if it's unrecoverable in general.

    which means that it's only okay in java core (or possibly when interfacing with custom hardware)

    anything that involves remote server communications or internal calculations, or basically anything that is not local hardware can be recovered from.... in theory.

    Well... Yeah, actually, that's probably accurate. It's hard to think of an example of a RuntimeException that's not just bubbling one up from core. The case may exist though...

  • (disco) in reply to sloosecannon
    sloosecannon:
    catch(ReadException | OtherIOException e)
    Is that real Java syntax? When did they introduce it?

    *hasn't written Java code since 1.5*

Leave a comment on “No Changes Please”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article