• captcha = dinky (unregistered) in reply to Matt
    Anonymous:
    Er... lets try this again, with quoting:
    Anonymous:

    Anonymous:
    I've used exceptions to break out of a bunch of inner functions while returning a result, and so of course you wouldn't tell the user, it's expected.

    Arg...this might be one of the most prevelent things I see when reviewing code of recent CS graduates. It is NEVER appropriate to use exceptions to determine program flow. Throwing and catching an error take up significantly more resources than checking to see if you have met a condition. Int32.TryParse was created for a reason (C#; however, most languages have something similar). It is a poor solution no matter how you look at it. Please, do everyone who will interact with your code a favor - never use exceptions for process flow.

    Well, mostly I agree. However, in Python, using exceptions for such purposes is encouraged, and the core language itself has, for instance, a StopIteration exception. On the newsgroups, using exceptions for flow control is advocated by the senior pythonistas and the BDFL. So, as long as the language the OP was writing in was python, one might forgive him or her.

    I gotta say, though, that the idea does make me a bit queasy (coming from a C++ background), but I'm otherwise quite fond of python, so I accept it.

    -matt

    Heh. Forum software strikes again.

  • (cs) in reply to BlackTigerX

    BlackTigerX:
    ya'll know that the real WTF is using java for such application in the first place [:D]

    Yeah - we all know they should have used Visual Basic!

  • (cs) in reply to squirrel

    squirrel:
    While it required a collective blindness and stupidity to make error data code effectively global, I have to say that Java encourages a special kind of typed exception hell which ridiculous bookkeeping. The nonsense is that you have to declare exception types that you may throw. This does not help design; no other language does this. You all know what you do when the compiler says that you're throwing something undeclared ... you use the IDE's refactor function to declare that you throw it. I hate fighting the compiler like that.

    Don't you know it's heretical to question the genius of Java's exception scheme?  Real programmers accurately foresee all the exceptional scenarios that may occur ahead of time and have a magical catch block that will make everything alright.

  • (cs) in reply to Sean
    Sean:
    This is proof that singletons are like crack.  Dangerous if not used properly.


    How would one properly use crack?  Singletons, I get, but crack?
  • (cs) in reply to JohnO
    JohnO:
    Real programmers accurately foresee all the exceptional scenarios that may occur ahead of time and have a magical catch block that will make everything alright.

    Exactly.  That is why so many examples (in texts and otherwise) say that the error checking was omitted for clarity.  The real programmers simply fill in the blanks.  Easy, peasy.

    Sincerely,

    Gene Wirchenko


  • (cs)
    Alex Papadimoulis:

    and, as one might expect, DataNotFoundException was implemented as a singleton, as were all other exception classes. A rather interesting choice for what was a high-traffic J2EE web application in a multithreaded environment ...

    The bug - sans observer, is doomed to fly singleton, from the factory to the oncoming windshield, where upon it's last sense in this world is static, only to be decorated by the fleeting instance of wiper-blades, and it's absence in the factory registry. Where upon a new iteration of the bug flies from the factory...without scope...

  • Fark Beans (unregistered) in reply to Matt B
    Matt B:
    masklinn:

    Ruby/RoR or Python/Django (or maybe Python/Turbogears if you prefer, I'd go with Django though).

    And if you want to toy with Ajaxy stuff, Prototype, MochiKit or Dojo (I think Django bundles Dojo, not sure though)

    Not PHP for sure (too bothersome to keep clean), no fscking way I'd use Perl, and I don't know ASP nor ASP.Net.

    So either RoR or Django, depending on the language you prefer (Ruby or Python).

    There are some differences between the RoR and the Django "philosophies" (ways of life) that may also play a role in your choice, but... that's an other issue



    this forum needs a huge rolleyes smiley


    Seriously... masklinn, you need to have a Narcissism checkup once in a while...
  • (cs) in reply to Djinn
    Djinn:
    ...Just as with becoming a programmer in general, you should have to get a license to use design patterns. You get a license for driving, guns, and hunting, because we don't want people mishandling these things and getting hurt. Same principle here.

    People  don't get hurt using crap software--unless they put their fist through the CRT in a fit of rage.

  • Nobody (unregistered) in reply to Shadow_x99
    Anonymous:
    What would you use as a Web Development Platform?
    ASP?
    ASP.NET?
    PHP4?
    PHP5?
    Perl?
    Ruby?
    Plain HTML with some AJAX with a SOAP Server?



    ANSI-C.
  • (cs) in reply to JohnO
    JohnO:

    squirrel:
    While it required a collective blindness and stupidity to make error data code effectively global, I have to say that Java encourages a special kind of typed exception hell which ridiculous bookkeeping. The nonsense is that you have to declare exception types that you may throw. This does not help design; no other language does this. You all know what you do when the compiler says that you're throwing something undeclared ... you use the IDE's refactor function to declare that you throw it. I hate fighting the compiler like that.

    Don't you know it's heretical to question the genius of Java's exception scheme?  Real programmers accurately foresee all the exceptional scenarios that may occur ahead of time and have a magical catch block that will make everything alright.

    Yeah. It goes something like this:

    try 
    {
        // Do some stuff
    } 
    catch
    {
        // This works kinda liek On Error Resume Next. Brillant!!!
    }
    
  • (cs) in reply to bugsRus
    bugsRus:
    Sean:
    This is proof that singletons are like crack.  Dangerous if not used properly.

    How would one properly use crack?  Singletons, I get, but crack?
    <font size="5">F</font>rom watching TV I have learned that the only thing to do with crack is to sell it and buy a BMW or other luxury ride,  pimp it out, wear a bunch of clocks round your neck,  hang with the homies--Sorry off topic, again.
  • (cs) in reply to Shadow_x99
    Anonymous:
    What would you use as a Web Development Platform?
    ASP?
    ASP.NET?
    PHP4?
    PHP5?
    Perl?
    Ruby?
    Plain HTML with some AJAX with a SOAP Server?


    Java. If I have the choice, it's servlets + a template engine.
  • robbak (unregistered) in reply to Xargon
    Xargon:
    Alex Papadimoulis:

    An unexpected exception occurred. Please try again.


    I've always wondered: what would an "expected exception" be, and would I be told if I encountered one?

    They are called "Expections" (as opposed to Expectations), and the name was coined here, after several wtfs where exception handling was used as the only exit from a loop.

    You recognise them by the fact that every programmer within kilometres start puking.

  • sika (unregistered) in reply to Djinn
    Djinn:

    Just as with becoming a programmer in general, you should have to get a license to use design patterns. You get a license for driving, guns, and hunting, because we don't want people mishandling these things and getting hurt. Same principle here.



    There is a licence available, only it's not called "licence" but a "degree in Computer Science" or "degree in Software Engineering"...

    Offcourse a  degree does not  guarantee that one does not make stupid  things, but at least the chances are smaller than with some self-educated guy who just walked in from the street and proclaimed to be a professional programmer.


  • LarsW (unregistered) in reply to squirrel
    squirrel:
    The nonsense is that you have to declare exception types that you may throw. This does not help design; no other language does this. <wink wink="">


    Actually, it DOES help design, if you stop and think rather than continue to code like you always have. If you feel that you are being overwhelmed with the number of exceptions thrown, that is a big warning sign that you have designed your program wrong. A lot of oetherwise really smart people get this wrong in my opinion, Bruce Eckel for instance, who in early editions of thinking in java had lots of example code wrapped in a big try/catch which then ignored the exception... like an earlier poster said, an equivalent of "on error resume".

    For example: When writing a system that did a lot of reading/writing to files, I found I had IO exceptions everywhere, which made the code messy, recovery difficult, and showed a lot of low level error messages to the end user. I realised the design was flawed, and when I refactored it so that it was more modularised (a logging subsystem, a db subsystem, etc that were separated much cleaner) things became much simpler. I could wrap all the different IOexceptions the subsystems could get and rethrew them as an exception that was appropriate for the subsystem, say, loggingexception. Then it is up to the user of the subsystem (myself, in this case), to decide what the app as a whole should do with this problem (warn user, but continue). On the other hand, if the db subsystem got an IOexception, there was no use continuing as that was the whole purpose of the app, so I called some generic shutdown routines in the "main" controller class. I did NOT throw a Runtime exception.

    In my opinion, having the checked exception is what has facilitated the creation of the huge number of high quality open source projects for Java.


    </wink>
  • Hansiola (unregistered) in reply to giannis

    giannis:
    Anonymous:
    Anonymous:
    What would you use as a Web Development Platform?
    ASP?
    ASP.NET?
    PHP4?
    PHP5?
    Perl?
    Ruby?
    Plain HTML with some AJAX with a SOAP Server?


    Python, of course. Maybe if this forum was coded in Python instead of ASP it would work without Javascript.


    ASP is not a programming language.

    It didn't say that ASP was a programming language....

    and nor are HTML or ASP.NET programing languages, so whats the problem?

    /H

  • Hansiola (unregistered) in reply to giannis

    giannis:
    Anonymous:
    Anonymous:
    What would you use as a Web Development Platform?
    ASP?
    ASP.NET?
    PHP4?
    PHP5?
    Perl?
    Ruby?
    Plain HTML with some AJAX with a SOAP Server?


    Python, of course. Maybe if this forum was coded in Python instead of ASP it would work without Javascript.


    ASP is not a programming language.

    Nor is AJAX a programming language...

     

    /H

  • MblSH (unregistered) in reply to OneFactor

    Err... doesn't take much of an imaginative effort for me - you've just pretty much described what we have to support...

    >

    Imagine if you will, the next attempt at dealing with the singleton databaseexception. A flyweight-cache so as to share common message instances, a factory to create the right style of database exception, coupled with the option to choose one's factory at runtime via a prototype, and then the database exceptions could use a template pattern instead of messages, an observer pattern to decouple logging the databaseexceptions, and a swarm of decorators to allow these exceptions to wrap on top of each other.

  • Asif Youcare (unregistered) in reply to Hansiola

    Maybe I'm dense (and I'm not a professional java programmer) but what is the problem with a singleton exception - and how is this related to the duplicate key - surely the DB wasn't asked to insert the object's reference?

    I'm sure you guys will tell me just how dense I am!

  • LarsW (unregistered) in reply to Asif Youcare
    Anonymous:
    Maybe I'm dense (and I'm not a professional java programmer) but what is the problem with a singleton exception - and how is this related to the duplicate key - surely the DB wasn't asked to insert the object's reference?

    I'm sure you guys will tell me just how dense I am!



    If two errors occur at the same time, the second thread will overwrite the error message of the first, and you get misleading error logs.
  • Anomymous (unregistered) in reply to triso

    Hey I'd prefer funny discussions instead of know-it-alls trying to make logical posts about illogical code.



  • (cs) in reply to LarsW
    Anonymous:
    Anonymous:
    Maybe I'm dense (and I'm not a professional java programmer) but what is the problem with a singleton exception - and how is this related to the duplicate key - surely the DB wasn't asked to insert the object's reference?

    I'm sure you guys will tell me just how dense I am!



    If two errors occur at the same time, the second thread will overwrite the error message of the first, and you get misleading error logs.

    There's also the problem that a thread that had no problems has access to a correctly created exception + error message that it has never had.

    Sooooo, what does this mean? This means that if you forget to inicialize the error message before throwing the exception, it doesn't mind, because it may already been inicializated with a completely unrelated message by some other thread at some point when that other thread needed to throw his own DataNotFoundException.

      //especification: return either null or another thread's message
    
      //no error here, since we get the same instance again later
      ////////DataNotFoundException.getInstance().setMessage(errMsg);
    
      throw DataNotFoundException.getInstance();
    
  • (cs) in reply to Satanicpuppy
    Satanicpuppy:
    versatilia:
    pbounaix:

    yeah i mean, who needs an exception stack trace, right?



    Don't get me started on those things... My eyes bleed every time I see a production system (read: public website) throw up pages and pages of stack trace when all you want is a user-friendly error message.

    I'm beginning to think exception handling is last on the 'to do' list of java programmers.

    As for tomcat fans and their insistence that a dual 1.5Ghz CPU with 2GB DDR is just not enough to handle their 100 user website...

    /troll


    Are there really Tomcat "fans". I use Tomcat exclusively when I need to host JSP, and even I hate that piece of crap. The documentation is scanty, the configuration is weird, debugging other peoples setup is a nightmare. If there was something better, I'd use it in a second.

    Try Resin Server. I always use the Open Source version, which has no proxy caching nor load balancing but works fine for single-server setups.

  • maht (unregistered) in reply to Thiago
    Anonymous:
    this wtf makes me remember of this famous donald knuth quote: "Premature optimization is the root of all evil (or at least most of it) in programming."


    From the book : Practical Common Lisp

    http://www.gigamonkeys.com/book/

    As has been said many times, and variously attributed to Donald Knuth, C.A.R. Hoare, and Edsger Dijkstra, premature optimization is the root of all evil.

    Knuth has used the saying several times in publications, including in his 1974 ACM Turing Award paper, "Computer Programming as an Art," and in his paper "Structured Programs with goto Statements." In his paper "The Errors of TeX," he attributes the saying to C.A.R. Hoare. And Hoare, in an 2004 e-mail to Hans Genwitz of phobia.com, said he didn't remember the origin of the saying but that he might have attributed it to Dijkstra.
  • (cs) in reply to Single Ton

    Anonymous:
    How can they be an architecture team if they don't use patterns?

    Singleton is a GoF pattern...
    And yes, it's often abused badly (as are most patterns).

    Worst pattern abuse I've come across was an application designed by someone who LOVED multitier (layered) applications and factories.
    It was a 3 layer application (typical MVC, dataaccess, business logic, display), nothing wrong with that (except that the reason given, decoupling the DB from the business logic and display was senseless as it was a monolithic platform, each component being set in stone by corporate (multinational) dictate).
    Then it got funny, each layer was itself divided into 3 layers (communication with the layer below, communication with the layer above, and the actual application logic).
    On the interface between EACH two layers there were abstract factories on either end to create the objects passed between them, as well as the objects receiving those objects to process them. Of course there were also factories to create the factories.
    So to display a single database record when a button was clicked you had to pass down through 9 application layers, creating 18 objects (factories and factory-factories) to create 9 DTOs, and then do the same again on the way back.
    So a single record retrieval would just to pass through the application architecture be creating 54 objects, plus whatever was needed inside the layers themselves to handle the request (business logic, display logic, database logic).
    Suffice to say the application was terribly slow, massively large (despite offering relatively little real functionality), and very hard to maintain because of all the bypasses that had over time been created to prevent having to go through all that for time critical operations (like printing a 100 page report which when going through the architecture would take 72 hours, but going direct would be done in maybe 10 minutes).

  • (cs) in reply to ferrengi
    ferrengi:
    Alex Papadimoulis:

    An unexpected exception occurred. Please try again.


    This is like saying: "We expect to have certain exceptions happen on a regular basis (which makes one start to think, gee, if I expect this to happen, it isn't really an exception is it?) however, you just did something which caused another type of error which was totally unexpected and the application is not designed to handle it. I guess it's not your day today but maybe if you try again in a few minutes, your luck will be in and it will work!"




    Imho you usually expect that a database connection could break down occasionally but you don't expect them to break all the time. Now, these are the cases that should be called exceptions. If this happens you want to pinpoint the cause, the location and the time scale of the problem and emit a fitting user-friendly error message..

    Seems fairly simple to me.

    But maintaining software has taught me (at least) one lesson: if something can be done the simple way, the developer will stick to the most roundabout solution.

    ---
    int param = new Integer( paramStr ).parseInt( paramStr );
  • (cs) in reply to jwenting
    jwenting:

    Singleton is a GoF pattern...
    And yes, it's often abused badly (as are most patterns).

    Worst pattern abuse I've come across was an application designed by someone who LOVED multitier (layered) applications and factories.
    It was a 3 layer application (typical MVC, dataaccess, business logic, display), nothing wrong with that (except that the reason given, decoupling the DB from the business logic and display was senseless as it was a monolithic platform, each component being set in stone by corporate (multinational) dictate).
    Then it got funny, each layer was itself divided into 3 layers (communication with the layer below, communication with the layer above, and the actual application logic).
    On the interface between EACH two layers there were abstract factories on either end to create the objects passed between them, as well as the objects receiving those objects to process them. Of course there were also factories to create the factories.
    So to display a single database record when a button was clicked you had to pass down through 9 application layers, creating 18 objects (factories and factory-factories) to create 9 DTOs, and then do the same again on the way back.
    So a single record retrieval would just to pass through the application architecture be creating 54 objects, plus whatever was needed inside the layers themselves to handle the request (business logic, display logic, database logic).
    Suffice to say the application was terribly slow, massively large (despite offering relatively little real functionality), and very hard to maintain because of all the bypasses that had over time been created to prevent having to go through all that for time critical operations (like printing a 100 page report which when going through the architecture would take 72 hours, but going direct would be done in maybe 10 minutes).



    I bet it was done in Java, using at least 5 different Apache frameworks.
  • (cs) in reply to jwenting
    jwenting:

    Anonymous:
    How can they be an architecture team if they don't use patterns?

    Singleton is a GoF pattern...
    And yes, it's often abused badly (as are most patterns).

    Worst pattern abuse I've come across was an application designed by someone who LOVED multitier (layered) applications and factories.
    It was a 3 layer application (typical MVC, dataaccess, business logic, display), nothing wrong with that (except that the reason given, decoupling the DB from the business logic and display was senseless as it was a monolithic platform, each component being set in stone by corporate (multinational) dictate).
    Then it got funny, each layer was itself divided into 3 layers (communication with the layer below, communication with the layer above, and the actual application logic).
    On the interface between EACH two layers there were abstract factories on either end to create the objects passed between them, as well as the objects receiving those objects to process them. Of course there were also factories to create the factories.
    So to display a single database record when a button was clicked you had to pass down through 9 application layers, creating 18 objects (factories and factory-factories) to create 9 DTOs, and then do the same again on the way back.
    So a single record retrieval would just to pass through the application architecture be creating 54 objects, plus whatever was needed inside the layers themselves to handle the request (business logic, display logic, database logic).
    Suffice to say the application was terribly slow, massively large (despite offering relatively little real functionality), and very hard to maintain because of all the bypasses that had over time been created to prevent having to go through all that for time critical operations (like printing a 100 page report which when going through the architecture would take 72 hours, but going direct would be done in maybe 10 minutes).



    I have a theory that when developers write code like this they emulate those funny bird species where the male tries to attract the female by a really weird and idiotistic dance. The weirder the dance the more your chances to mate.
  • (cs) in reply to ammoQ
    ammoQ:
    jwenting:

    Singleton is a GoF pattern...
    And yes, it's often abused badly (as are most patterns).

    Worst pattern abuse I've come across was an application designed by someone who LOVED multitier (layered) applications and factories.
    It was a 3 layer application (typical MVC, dataaccess, business logic, display), nothing wrong with that (except that the reason given, decoupling the DB from the business logic and display was senseless as it was a monolithic platform, each component being set in stone by corporate (multinational) dictate).
    Then it got funny, each layer was itself divided into 3 layers (communication with the layer below, communication with the layer above, and the actual application logic).
    On the interface between EACH two layers there were abstract factories on either end to create the objects passed between them, as well as the objects receiving those objects to process them. Of course there were also factories to create the factories.
    So to display a single database record when a button was clicked you had to pass down through 9 application layers, creating 18 objects (factories and factory-factories) to create 9 DTOs, and then do the same again on the way back.
    So a single record retrieval would just to pass through the application architecture be creating 54 objects, plus whatever was needed inside the layers themselves to handle the request (business logic, display logic, database logic).
    Suffice to say the application was terribly slow, massively large (despite offering relatively little real functionality), and very hard to maintain because of all the bypasses that had over time been created to prevent having to go through all that for time critical operations (like printing a 100 page report which when going through the architecture would take 72 hours, but going direct would be done in maybe 10 minutes).



    I bet it was done in Java, using at least 5 different Apache frameworks.

    Wrong guess, it was done in C++ using no frameworks whatsoever.
    It did use copious code generation by Rational Rose though, which added even more headaches as it had a tendency to silently removed code it hadn't itself generated even when placed in the "safe" areas it indicates for such.

  • (cs) in reply to LarsW

    Anonymous:
    squirrel:
    The nonsense is that you have to declare exception types that you may throw. This does not help design; no other language does this. <WINK wink="">

    Actually, it DOES help design, if you stop and think rather than continue to code like you always have.

    ...
    For example: When writing a system that did a lot of reading/writing to files, I found I had IO exceptions everywhere, which made the code messy, recovery difficult, and showed a lot of low level error messages to the end user. I realised the design was flawed, and when I refactored it so that it was more modularised (a logging subsystem, a db subsystem, etc that were separated much cleaner) things became much simpler.

    ...
    In my opinion, having the checked exception is what has facilitated the creation of the huge number of high quality open source projects for Java.

    </WINK>

    Talk about the tail wagging the dog.  So forced declarations in Java are good because they made you realize how poorly modularized your initial design was?  Sorry, but you should have had modular design, regardless of exception handling.  Are you saying that if you tried to code in c# you wouldn't write good, modular code because you weren't forced to handle or declare exceptions at the method level?

  • rshields (unregistered) in reply to mikeyd
    Anonymous:
    I've used exceptions to break out of a bunch of inner functions while returning a result, and so of course you wouldn't tell the user, it's expected.


    Why don't you submit the code, maybe it'll get used on the main page ;)
  • Bobbo (unregistered) in reply to LarsW
    In my opinion, having the checked exception is what has facilitated the creation of the huge number of high quality open source projects for Java.

    Oh man, I thought for most of the post you were being serious. Thanks for including the tip-off.

  • (cs) in reply to rshields
    Anonymous:
    Anonymous:
    I've used exceptions to break out of a bunch of inner functions while returning a result, and so of course you wouldn't tell the user, it's expected.


    Why don't you submit the code, maybe it'll get used on the main page ;)


    This method can be usefull if carefully applied within a narrow context, e.g. input validation.

    Instead of a relatively verbose input validation

    public void processRequest ( Request request, Response response ) throws IOException {
      if (isEmpty(request.getParameter("CUSTNO"))) {
        showErrorPage(request, response, "Customer number must not be empty!", "CUSTNO");
         return;
      }

      if (isEmpty(request.getParameter("CUSTNAME"))) {
        showErrorPage(request, response, "Customer name must not be empty!", "CUSTNO");
         return;
      }
    // ... process request
    }

    you only have to write


    public void processRequest ( Request request, Response response ) throws IOException, ValidationException {
    validateNotEmpty(request, response, "CUSTNO", "Customer number must not be empty!");
    validateNotEmpty(request, response, "CUSTNAME", "Customer name must not be empty!");

    // ... process request
    }

    and the surrounding framework cares for the rest. (validateNotEmpty throws a ValidationException if validation fails, thus breaking out of processRequest)

  • (cs)

    ARRGGH!!!! Its that dreaded singleton! I HATE SINGLETONS! HATE HATE HATE!

    It wouldn't be so bad, but I estimate that half of our crashes in production code are caused by singleton where there was no need for them. (And all in classes created by a chief programmer who thankfully is no longer here)

    P.S. Did I mention I hate singleton?

  • (cs)

    My favorite pattern is Argyle....

  • (cs) in reply to Sweets

    Sweets:
    My favorite pattern is Argyle....

     

    Bah, we all know plaid is superior. 

  • bleargh (unregistered) in reply to JohnO

    wtf.  Yes real programmers accurately see forsee checked exceptions (the compiler helps).   There is nothing magical about using a catch block to log the error and let the user know something happened.

  • (cs) in reply to Shadow_x99
    Anonymous:
    What would you use as a Web Development Platform?
    ASP?
    ASP.NET?
    PHP4?
    PHP5?
    Perl?
    Ruby?
    Plain HTML with some AJAX with a SOAP Server?
    An awk script, and some perl and bash to run the awk script.

    Yes I have, it was evil. So am I.
  • Anonymous (unregistered) in reply to jwenting
    jwenting:

    Anonymous:
    How can they be an architecture team if they don't use patterns?

    Singleton is a GoF pattern...
    And yes, it's often abused badly (as are most patterns).

    Worst pattern abuse I've come across was an application designed by someone who LOVED multitier (layered) applications and factories.
    It was a 3 layer application (typical MVC, dataaccess, business logic, display), nothing wrong with that (except that the reason given, decoupling the DB from the business logic and display was senseless as it was a monolithic platform, each component being set in stone by corporate (multinational) dictate).
    Then it got funny, each layer was itself divided into 3 layers (communication with the layer below, communication with the layer above, and the actual application logic).
    On the interface between EACH two layers there were abstract factories on either end to create the objects passed between them, as well as the objects receiving those objects to process them. Of course there were also factories to create the factories.
    So to display a single database record when a button was clicked you had to pass down through 9 application layers, creating 18 objects (factories and factory-factories) to create 9 DTOs, and then do the same again on the way back.
    So a single record retrieval would just to pass through the application architecture be creating 54 objects, plus whatever was needed inside the layers themselves to handle the request (business logic, display logic, database logic).
    Suffice to say the application was terribly slow, massively large (despite offering relatively little real functionality), and very hard to maintain because of all the bypasses that had over time been created to prevent having to go through all that for time critical operations (like printing a 100 page report which when going through the architecture would take 72 hours, but going direct would be done in maybe 10 minutes).


    Did this someone go on to found Interface21? :D
  • (cs) in reply to sika

    I agree, a degree/certificate or license does not gaurantee any common sense or misuse of knowledge gained during the process of getting the piece of paper.  Every profession has it's 'crack heads' and they, like us, most likely spend part of their work day looking at examples of these 'wtfery'. 

     

    I disagree that a choice of a certain type of platform (which always seems to flame up) to produce a usable product would enhance the end user's experience.  At one time the choices ranged in degrees of Assembly and I'm sure you could still write applications in assembly but you would likely be crazy by the time you were done. 

  • Cyprian (unregistered) in reply to Anonymous
    Anonymous:
    jwenting:

    Anonymous:
    How can they be an architecture team if they don't use patterns?

    Singleton is a GoF pattern...
    And yes, it's often abused badly (as are most patterns).

    Worst pattern abuse I've come across was an application designed by someone who LOVED multitier (layered) applications and factories.
    It was a 3 layer application (typical MVC, dataaccess, business logic, display), nothing wrong with that (except that the reason given, decoupling the DB from the business logic and display was senseless as it was a monolithic platform, each component being set in stone by corporate (multinational) dictate).
    Then it got funny, each layer was itself divided into 3 layers (communication with the layer below, communication with the layer above, and the actual application logic).
    On the interface between EACH two layers there were abstract factories on either end to create the objects passed between them, as well as the objects receiving those objects to process them. Of course there were also factories to create the factories.
    So to display a single database record when a button was clicked you had to pass down through 9 application layers, creating 18 objects (factories and factory-factories) to create 9 DTOs, and then do the same again on the way back.
    So a single record retrieval would just to pass through the application architecture be creating 54 objects, plus whatever was needed inside the layers themselves to handle the request (business logic, display logic, database logic).
    Suffice to say the application was terribly slow, massively large (despite offering relatively little real functionality), and very hard to maintain because of all the bypasses that had over time been created to prevent having to go through all that for time critical operations (like printing a 100 page report which when going through the architecture would take 72 hours, but going direct would be done in maybe 10 minutes).


    Did this someone go on to found Interface21? :D


    I think you were joking, but I have to say this anyway. The only people I see making fun of Spring are those that just can't comprehend it. Generally speaking, they are also junior or junior/mid level programmers who think they are seniors. A pretty common occurence.

    Anyway, if you don't think Spring is great, you should look at it again. It brings things to the Java platform that have been lacking for years and that make life so much easier. And the core concepts are just great!

    Onto another topic....I know this forum and its participants lean heavily towards the .NET/MS side of things, but if you haven't already you have to check out Rails. Seriously, it is that good.

    BTW, just so there is no confusion. I have done Java/J2EE programming for the past 8 years, moved to .NET 2005 about 3 months ago and I don't think either can hold a candle to the productivity I get out of Rails.
  • Cringer, He-Man's Battlecat (unregistered) in reply to Casual WTF Viewer
    Anonymous:

    Throwing and catching an error take up significantly more resources than checking to see if you have met a condition. Int32.TryParse was created for a reason (C#; however, most languages have something similar). It is a poor solution no matter how you look at it. Please, do everyone who will interact with your code a favor - never use exceptions for process flow.



    Int32.TryParse calls Number.TryParseInt32 which calls a dozen other functions.  Convert.ToInt32 follows the same path in .NET 2.0, but a totally different path in .NET 1.1.  TryParse didn't exist on many of the object types in .NET 1.0 and .NET 1.1.  I'm trying to find the processor savings by calling this function chain with tramp data versus executing a stack trace and creating an exception.

    For that matter, exceptions may be misnamed but I do believe they can aid in code readability.  They don't help with code readability or maintainability if they are overused, but any aspect of programming (in any language) can cause chaos in that manner.

    Yes, this code makes sense:

    if(Int32.TryParse(input, out result) == true)

    is clean and can be read and still make sense.  But what about...

    if(CustomLibrary.PositionObject(x, y, z) == false)

    False?  False what?  What does false mean?  Well, let's make it return 0 for normal operations and a negative number for error states!

    if(CustomLibrary.PositionObject(x, y, z))

    Well that makes sense, at least.  It's readable, if you're used to the shorthand boolean expressions.

    What about error checking though?  We just completely forgot about error checking!  We better add that in.

    int errorCode = CustomLibrary.PositionObject(x, y, z);
    switch(errorCode)
    {
        case -1:      // File not found error.
                          HandleFileNotFoundError();
                          break;
        case -2:      // Resource unavailable.
                          HandleResourceUnavailableError();
                          break;
        ...
        default:      // No error.  Celebrate!
                        HandleUserInput();
                        break;
    }

    Oh, eh, that's fantastic.  After every line of code we do a complete error check.  That makes for REALLY readable code.

    So rather than concentrate on writing code that first and foremost does its job - you end up writing code that tries (and will fail!) to take into account every possible error that might occur.  Whereas with exceptions you - yes, pick and choose - pick and choose the errors you want to recover from at your level.

    try
    {
        CustomLibrary.PositionObject(x, y, z);
        HandleUserInput();
    }
    catch(FileNotFoundException ex)
    {
        // Handle error.
    }
    catch(ResourceUnavailableException ex)
    {
        // Handle error.
    }

    The processing code is written and can be read over without attempting to mentally discard the error handling code.  The exceptions come at the end, resembling a goto (and I think this is most programmers objection to it, despite the fact that sensible goto use is advocated in Code Complete, 2nd Ed), but the exceptions at the end allow you to centralize your error processing.

    Exceptions propagate even, so if you throw a HolyShitTheSystemIsOnFireException and don't handle it until your main program routine, there's nothing you have to do to support that behavior.  You don't end up with...

    int Routine1()
    {
        int errorResult = CustomLibrary.PositionObject(x, y, z);
        if(errorResult < 0)
        {
            return errorResult;
        }
    }

    int Routine()
    {
        int errorResult = Routine1();
        if(errorResult < 0)
        {
           return errorResult;
        }
    }

    The programmer actively declares what exceptions they can handle.

    Flow control:  I don't like using exceptions for flow control but they do provide a great deal more meaning than integer or boolean result codes.  You could create an enumeration I suppose for every function and have the function return one of the enumerated values to make it clear exactly what occurred -- but this seems to be a waste of time to me.

    As for the supposed cost of exceptions there are tons of articles and research pointing both ways on the supposed exceptional cost.  "The True Cost of Exceptions" (http://www.developerfusion.co.uk/show/5250/) is one such article that tries to debunk the "exceptions are expensive" myth, with enough details to satisfy most folks.  In "Writing Managed Code" (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/fastmanagedcode.asp) by Jan Gray, the Microsoft CLR Performance Team, she leaves testing exception handling as an exercise to the reader.  If exceptions were a huge performance impact would they not have been covered in this paper?

    Finally, CodeProject has an excellent article entitled "Performance Implications of Exceptions in .NET" (http://www.codeproject.com/dotnet/ExceptionPerformance.asp).  The author goes into detail as to what he measured, how he measured it, and provides a fairly substantial analysis that the footprint of exceptions is minimal as compared to the rest of the architecture.

    The primary objection I've seen to exceptions is that of performance - and I don't believe they are the problem in those cases.  If you're objecting to exceptions use as flow control devices then you need to step back and reconsider:  when you call a function, you should expect it to succeed.  If you expect it to fail, why not pretest the data?  If the function fails it has encountered an exception in its ability to process data and it reports that exception to you.  Hell, I'd rather say they aid in flow control rather than defeat it because they allow the flow to be distinctly defined.

    But, whatever, I'm sure this will be torn to pieces by the zealots who hang out here.

    (Edit:  nice captcha.  Postal.  *snicker*)
  • (cs) in reply to Cringer, He-Man's Battlecat

    Anonymous:
    But, whatever, I'm sure this will be torn to pieces by the zealots who hang out here.

    How right you were. :) 

    Have you ever considered not using stupid ifs? IE if ( x ) as opposed to if ( x == true) or if ( !x ) as opposed to if ( x == false ).

    That really bugs the hell out of me.

  • (cs) in reply to JohnO

    I also detest:

    if ( a == b ) then x = true else x = false;

    when

    x = a == b;

    is so much simpler.

     

  • (cs)

    I have a theory on how this happened.
    - The programmer was advised that in a system that uses exceptions, an "out of memory" exception should be statically allocated on startup, so that if it occurs you don't run into the problem of failing to allocate memory for your error message.
    - The programmer made this instance global.
    - The programmer then learned that "all globals are evil, use singletons instead".
    - Then, somehow, it morphed from just the "out of memory" exceptions to all exceptions.

    (Of course, if your singleton dynamically allocates the string for the error field, you'd actually be back to start for the "out of memory" condition.)

    Am I giving too much credit?

  • (cs) in reply to Stoffel
    Stoffel:

    - The programmer was advised that in a system that uses exceptions, an "out of memory" exception should be statically allocated on startup, so that if it occurs you don't run into the problem of failing to allocate memory for your error message.

    Am I giving too much credit?


    Anyone ever wrote a program that explicitely throws a "out of memory" exception?
  • (cs) in reply to Casual WTF Viewer
    Anonymous:

    Anonymous:
    I've used exceptions to break out of a bunch of inner functions while returning a result, and so of course you wouldn't tell the user, it's expected.

    Arg...this might be one of the most prevelent things I see when reviewing code of recent CS graduates. It is NEVER appropriate to use exceptions to determine program flow. Throwing and catching an error take up significantly more resources than checking to see if you have met a condition. Int32.TryParse was created for a reason (C#; however, most languages have something similar). It is a poor solution no matter how you look at it. Please, do everyone who will interact with your code a favor - never use exceptions for process flow.



    Another which says what I think
  • (cs) in reply to sika
    Anonymous:
    Djinn:

    Just as with becoming a programmer in general, you should have to get a license to use design patterns. You get a license for driving, guns, and hunting, because we don't want people mishandling these things and getting hurt. Same principle here.



    There is a licence available, only it's not called "licence" but a "degree in Computer Science" or "degree in Software Engineering"...

    Offcourse a  degree does not  guarantee that one does not make stupid  things, but at least the chances are smaller than with some self-educated guy who just walked in from the street and proclaimed to be a professional programmer.




    Really? I've found it's quite the opposite.
  • (cs) in reply to SeekerDarksteel
    SeekerDarksteel:

    Sweets:
    My favorite pattern is Argyle....

     

    Bah, we all know plaid is superior. 



    On the contrary, Argyle lends itself to far more efficient development processes, and performs twice as well as plaid in core benchmarks.
  • Cyprian (unregistered) in reply to Djinn
    Djinn:
    Anonymous:
    Djinn:

    Just as with becoming a programmer in general, you should have to get a license to use design patterns. You get a license for driving, guns, and hunting, because we don't want people mishandling these things and getting hurt. Same principle here.



    There is a licence available, only it's not called "licence" but a "degree in Computer Science" or "degree in Software Engineering"...

    Offcourse a  degree does not  guarantee that one does not make stupid  things, but at least the chances are smaller than with some self-educated guy who just walked in from the street and proclaimed to be a professional programmer.




    Really? I've found it's quite the opposite.


    Two people interview for the same position and they both look about the same in terms of experience and skill. Money is not a problem. One has a degree (from a real school, not Devry, Joe Blow CC or ITT Tech or something) and one does not. Who do you hire? I would hire the one with a degree from a real school 10 out of 10 times. This at least shows some sort of commitment and investment (time and money).

    A degree does not guarantee that the person will be good, and not having a degree does not mean they will be bad (one of the better programmers I have known does not have a degree), but generally speaking, self-educated people take shortcuts and are not forced to do the hard things in many cases.

    To take a different route: would you let a doctor operate on you if they were self taught? Would hire a lawyer that didn't goto law school?

    This phenomenon where we allow accountants to become programmers just because they want to without any formal education is what gives us some truly crappy projects. Think back to the .com days when everyone was becoming a developer overnight because the money was there....it only hurt the field as a whole.


Leave a comment on “Exceptional Singleton”

Log In or post as a guest

Replying to comment #:

« Return to Article