• Cyrus (unregistered)

    I don't think they quite understand stack unwinding; though I'm interested to hear someone defend this, could be interesting.

    Captcha: Bling, word.

  • (cs)

    I especially like the fact that every email sent out will include %%FirstName%% and %%LastName%% because of the ToLower() call in the swtich.

  • Benanov (can't login) (unregistered)

    It's completely useless! String.Replace(string1,string2) is s/string1/string2/g

    Captcha: ewww (how true)

  • pete (unregistered)

    my great new list implementation:

    public static Exception obfuscateArray(String[] members)
{
  Exception e = new Exception(Integer.valueOf(mebers.length));

  for(int i=0; i < members.length; i++)
  {
    try
    {
      throw new Exception(members[i], e);
    }
    catch(Exception x)
    { 
       e = x;
    }
  }
  return e;
}
  • ntheory (unregistered) in reply to pete

    "mebers" causes an error. Oh well, guess I can't put that into production yet.

  • Mikkel Høgh (unregistered)

    This is hilarious... Who said it wasn't possible to make a simple mater of string replacement impossibly complicated - even in C#.

  • shenme (unregistered)

    Is there some reason you'd code '%' two different ways, Unicode "\u0025" or 'normal' "%" ?

    Is there some rule saying you couldn't just say "switch (match.Value.toLower())" and then 'case "%%username%%":' ?

    Does 'Body.Replace("%%password%%",' do case-insensitive matching, in case the instance was "%%pASSword%%" ?

    -- I'm a pessimist about probabilities; I'm an optimist about possibilities. Lewis Mumford (1895-1990)

  • (cs)

    Like many of my managers liked to say, "Our program should never fail." Hence:

    try {
anyOfMyFunctions();
} catch (Exception e) {
System.out.println("Exception!");
}

    P.S. I'll kill you if you tell them about Throwable and Error.

  • Odhran (unregistered)

    What a bloody awful piece of code!!

    They obviously never heard of XSL transforms either ... for shame!

  • (cs) in reply to shenme
    shenme:
    Is there some reason you'd code '%' two different ways, Unicode "\u0025" or 'normal' "%" ?

    Is there some rule saying you couldn't just say "switch (match.Value.toLower())" and then 'case "%%username%%":' ?

    Does 'Body.Replace("%%password%%",' do case-insensitive matching, in case the instance was "%%pASSword%%" ?

    \u0025 and % is exactly the same. You could do case "%%username%%" but that's not really the point, string.Replace replaces everything it finds, so you could just call all the Replace things, no need for Regex either. And string.Replace is case-sensitive so it would leave "%%pASSword%%"

    And then returning the exception, this is just one big WTF.

  • gram (unregistered)

    they also haven't heard about Regex.Replace, which makes life easier (: but it's true, xslt is the right way

  • Marcin (unregistered)

    Consider: the use of exceptions will prevent the mail being sent, preventing erroneous behaviour.

    The caller might want to defer exception handling in order to do generic cleanup etc. that would otherwise have to be replicated in each handler. Java/C#/C++ exceptions do impose certain style costs in that regard, and the writer of this code might want to avoid that.

  • gram (unregistered)

    if you want to defer exception handling, you just don't need to catch it here...

  • John Cowan (unregistered)

    Sure, why not return an exception? It's a first-class object; you can pass it around however you like, pick it apart, whatever. Nothing says you have to throw it.

  • (cs)

    If I were to call a method, and I noticed that the return type was an exception, I would consider sending the damn email myself.

  • Smudge (unregistered)

    Whenever I see "== true" or "== false", it's always a guarantee that the rest of the code will be awful too. This one didn't disappoint,

  • Frzr (unregistered)

    "Catch and Release is more than just a way of hurting fish for fun." -- Dogbert

    Captcha: atari, where you had no exceptions.

  • (cs) in reply to Odhran
    Odhran:
    What a bloody awful piece of code!!

    They obviously never heard of XSL transforms either ... for shame!

    Yeah, because someone who would write something like this needs to be turned loose with XSLT...

    ... not saying XSLT is the wrong way, just this seems like the wrong person to attempt to use it!

  • willy (unregistered) in reply to Smudge
    Smudge:
    Whenever I see "== true" or "== false", it's always a guarantee that the rest of the code will be awful too. This one didn't disappoint,

    I dunno, in any language I try to make things as explicit as possible. having '== true' or whatever (although a bit redundant makes it obvious as to what the return type is being evaluated in the conditional without the need to investigate further.

    I do a lot of code maintenance, so maybe it's just me, but when I'm skimming through existing code after its been written, little visual queues like this save time and brainpower.

  • Your Name (unregistered) in reply to Smudge

    I agree with you on single comparisons, but when there are muliple ands and ors, it doesn't hurt to really say what you mean.

    I hope you aren't one of those people who also berates others for using excess parentheses, because they "slow down the compiler" or something.

  • AndrewB (unregistered) in reply to Smudge
    Smudge:
    Whenever I see "== true" or "== false", it's always a guarantee that the rest of the code will be awful too. This one didn't disappoint,

    Ever heard of readability?

  • Fredric (unregistered)

    I must say that I had never thought of returning an exception until now.

    It's quite a strange way of returning an error code, but essentially it's the same thing.

    With the difference that Null means the function succeeded, while usually if a function returns Null you'd expect it to have failed. In this case it fails if it actually returns something...

    And the lower/upper case stuff... That's just dumb...

    captcha: bathe, is that even a real word?

  • (cs) in reply to Your Name
    Your Name:
    I agree with you on single comparisons, but when there are muliple ands and ors, it doesn't hurt to really say what you mean.

    I hope you aren't one of those people who also berates others for using excess parentheses, because they "slow down the compiler" or something.

    A few years ago, I worked with this woman who was a former Lisp programmer, and she used to bury her expressions in lots of layers of parentheses, just because the compiler would effectively ignore them:

    if ((( x == 3 ))) { ... }

    On short expressions, it's not so bad, but on very complex expressions with multiply nested sub-groups, it was a horror to manually scan. I spent a whole lot of time normalizing her code

  • el jaybird (unregistered) in reply to Frzr
    Frzr:
    atari, where you had no exceptions.

    Shaka, when the walls fell.

  • Anonymous (unregistered) in reply to Smudge

    My favorite is the gradual maintenance that eventually results in abominations like this:

    if(!(!foo == !false))

    ... logic parse error, core dumped ...

  • Havic (unregistered)

    I must say that I don't see a problem returning an error from the method, though I should think that you would want to catch explicit errors and only return errors you were expecting, any unknown errors could just be rethrown. In this way the calling function could check for null for success, anything else was a minor error probably indicating that the email couldn't be sent. I've done email routines this way many times. I usually just tell the user that there was a problem sending the email and then spit out the error description.

  • Jon (unregistered) in reply to Fredric
    Fredric:
    captcha: bathe, is that even a real word?

    Ask your coworkers if you stink

    captcha: paint

  • digdug (unregistered) in reply to gram
    gram:
    they also haven't heard about Regex.Replace, which makes life easier (: but it's true, xslt is the right way
    Nope, the Right Way is a templating language (free template or the like) rather than XML/XSLT.
  • Brian (unregistered)

    Am I the only one to think that naming template files with an extension of .tmp is a WTF?

  • n (unregistered) in reply to el jaybird
    el jaybird:
    Frzr:
    atari, where you had no exceptions.

    Shaka, when the walls fell.

    YAYAYAAYY!!!! You made my day!

    Temba, his arms wide.

    (captcha -- xevious, one of my favorite old video games. I can still hum the theme song.)

  • htg (unregistered) in reply to Havic

    I must say that I don't see a problem returning an error from the method, though I should think that you would want to catch explicit errors and only return errors you were expecting

    Define your own exception, e.g., MyMailSendException, with useful fields.

    Catch email and I/O exceptions, then use them to throw your own MyMailSendException, thus protecting the code that calls your code from the email/IO/etc exceptions.

    But returning exceptions, that's nutty. However it is less CPU overhead than executing code in a try..catch statement (well, historically in Java, I don't know about now, or C#). Also simply catching the highest level Exception is not nice, that's why subclasses exist!

    This code does explain spam emails I get with %%username%% in them though.

    Catch and Release, yeah, fishy, but Catch and Return is more accurate here...

  • (cs) in reply to n
    n:
    el jaybird:
    Frzr:
    atari, where you had no exceptions.

    Shaka, when the walls fell.

    YAYAYAAYY!!!! You made my day!

    Temba, his arms wide.

    (captcha -- xevious, one of my favorite old video games. I can still hum the theme song.)

    Somewhat off topic, but...

    you know you're getting old when you feel old because you get not only both of these references, but the original references that came (way) before them..

  • Nurgle (unregistered) in reply to Smudge

    if (true == HateReadableCode) { return NoCookie; } else if (false == HateReadableCode) { return ChocolateChip; } else { return FileNotFound; }

    captcha: mmmm... yummy cookies...

  • htg (unregistered)

    Also shouldn't the entire regex stuff be the C# equivalent of the single line in Perl:

    $template ~= s/%%(.$)%%/$t{"$1"}/g;

    although when I've done stuff before (a few years ago, and in Perl which I'm now rusty in) I used to use {{variable}} in my templates (usually HTML, but did have email templates) instead of %%variable%%.

    Now I'd use a proper templating engine.

    %t = { captcha => "pirates"; };

  • NoName (unregistered) in reply to Smudge
    Smudge:
    Whenever I see "== true" or "== false", it's always a guarantee that the rest of the code will be awful too. This one didn't disappoint,

    Usually, I'd agree. However, I admit to having used this syntax in weakly typed languages (like Python), because I used a "trinary" variable. That is, it could be true, false, or an object. So the check "foo == true" made perfect sense, because if "foo" is an object, it will cast to "true", but that's different from foo actually being equal to true.

    However, in strongly-typed langugaes, there's no good reason for that.

  • Nurgle (unregistered) in reply to Nurgle

    Oops, forgot to qutoe above...

    Smudge: Whenever I see "== true" or "== false", it's always a guarantee that the rest of the code will be awful too. This one didn't disappoint,
  • Peter Antoine (unregistered) in reply to snoofle
    snoofle:
    n:
    el jaybird:
    Frzr:
    atari, where you had no exceptions.

    Shaka, when the walls fell.

    YAYAYAAYY!!!! You made my day!

    Temba, his arms wide.

    (captcha -- xevious, one of my favorite old video games. I can still hum the theme song.)

    Somewhat off topic, but...

    you know you're getting old when you feel old because you get not only both of these references, but the original references that came (way) before them..

    I apologise for being equally as old but, http://en.wikipedia.org/wiki/Row_of_bombs.

    DevPack ST ahhhh..... the good old days. (not quite as good as DevPack on the 800XL --- now that was coding)

  • Andrew Bell (unregistered) in reply to htg

    Returning exceptions isn't so nutty. Not to say that this is good code, but it could be useful. Maybe some callers will care that things failed, and some callers don't care. Those that care can check to see if an exception is returned. Those that don't care don't have to do ANYTHING. To ME, this is nicer than:

    try { call(); } catch (Exception ex) {}

    Returning the exception provides everything you want to know IF you want to know it.

  • htg (unregistered) in reply to Andrew Bell
    Andrew Bell:
    Returning exceptions isn't so nutty. Not to say that this is good code, but it could be useful. Maybe some callers will care that things failed, and some callers don't care. Those that care can check to see if an exception is returned. Those that don't care don't have to do ANYTHING. To ME, this is nicer than:

    Or you could use a policy of "Catch And Consume" within the method and simply return a boolean, true for successfully sent, false for failed to send, and filenotfound otherwise.

    Regardless returning an Exception is silly, you might as well return any type of object, e.g., in this case a String would suffice with the error message inside.

    Or is your optional code, i.e.,

    if (exception != null) { if (exception instanceof FileNotFoundException) { blah } else if (exception instanceof EmailNotSentException) { blah } else .... else { have we tried all possible exceptions? I'm not sure, the javadoc didn't say what the possible exceptions would be, but when we use a try/catch the IDE will let us know } }

    really that good?

    captcha: stinky. yup, it certainly is.

  • dwm (unregistered) in reply to htg
    htg:

    %t = { captcha => "pirates"; };

    Your Perl really is rusty. That should be:

    %t = (
    captcha => "pirates", );

  • Eam (unregistered) in reply to John Cowan
    John Cowan:
    Sure, why not return an exception? It's a first-class object; you can pass it around however you like, pick it apart, whatever. Nothing says you *have* to throw it.

    Sarcasm usually doesn't come across clearly in text, so I'm going to have to assume you're not joking.

    Please stay away from all languages that treat exceptions as first-class objects.

  • Smudge (unregistered) in reply to AndrewB
    AndrewB:
    Smudge:
    Whenever I see "== true" or "== false", it's always a guarantee that the rest of the code will be awful too. This one didn't disappoint,

    Ever heard of readability?

    Ever heard of DRY? If you're going to test a boolean against a boolean to get a boolean, why stop there? Why don't you test the result of that against another boolean, just to be sure?

  • So..... (unregistered) in reply to Smudge
    Smudge:
    Whenever I see "== true" or "== false", it's always a guarantee that the rest of the code will be awful too. This one didn't disappoint,

    Very true! One of me pet hates is when people put

    if(true==isEnabled){}</code?

    I know that it stops you accidentally assigning the value but come on it is just wrong!
  • woohoo (unregistered) in reply to Andrew Bell
    Andrew Bell:
    Returning exceptions isn't so nutty. Not to say that this is good code, but it could be useful. Maybe some callers will care that things failed, and some callers don't care. Those that care can check to see if an exception is returned. Those that don't care don't have to do ANYTHING. To ME, this is nicer than:

    try { call(); } catch (Exception ex) {}

    Returning the exception provides everything you want to know IF you want to know it.

    sorry, but no. it is nutty to return exceptions. one of the main reasons for exceptions is the fact that you are required to handle them (with the notable exception ;o) of runtime/unchecked exceptions, which are nevertheless always handed up the call stack and manifest themselves somewhere), and it is usually not just for the fun of it if any method throws an exception.

    if you are just returning exceptions it is even easier to just ignore or swallow them unnoticed.

    the fact that very many exceptions are indeed "handled" in the way you are insinuating in your code snippet just shows how many developers do not have the dimmest of ideas about the concepts of "their" languages. code like above should immediately result in a release - of the developer in question, that is ;o)

    thankfully modern IDEs (like eclipse e.g.) issue warnings about empty blocks, so it is easier to nail down whick devloper is to be "released"... ;o)

    captcha: sanitarium ;o))

  • Smudge (unregistered) in reply to woohoo
    it *is* nutty to return exceptions. one of the main reasons for exceptions is the fact that you are *required* to handle them (with the notable exception ;o) of runtime/unchecked exceptions,

    ...which are all that C# has.

  • Baston (unregistered) in reply to Frzr
    Frzr:
    "Catch and Release is more than just a way of hurting fish for fun." -- Dogbert

    Catch and Throw is far worse :o)

  • Stephen (unregistered) in reply to snoofle
    snoofle:
    A few years ago, I worked with this woman who was a former Lisp programmer, and she used to bury her expressions in lots of layers of parentheses, just because the compiler would effectively ignore them:

    if ((( x == 3 ))) { ... }

    I learned C on a machine with 64K RAM. That compiler had a quirk: every time it ran into an open-parenthesis or a left-curly-bracket, something inside it recursed, with neither a recursion limit nor stack bounds-checking. Its behavior under stack overflow usually wasn't to crash. Instead it would generate bad code. (Oh, the second half of my function? I guess I didn't need it anyway... That illegal assembly code the compiler generated? It must be the assembler's problem...)

    If your coworker's post-death fate should be the firey place down below, that old compiler is probably waiting for her. :-)

  • Anon (unregistered) in reply to So.....

    I will stand up and defend if(false==something) because, personally, I read code like this:

    if (something happens) { do something; }

    If the statement in the if is required to be false that is abnormal, and I don't like to include anomalies in my code without making them highly visible.

    Doing if(true==something) is retarded, though.

  • htg (unregistered) in reply to dwm
    dwm:
    htg:

    %t = { captcha => "pirates"; };

    Your Perl really is rusty. That should be:

    %t = (
    captcha => "pirates", );

    I saw that after posting, no edit functionality! (I had written $t{'captcha'} = "pirates"; and decided to change it, honest!)

  • webdev101 (unregistered) in reply to snoofle
    snoofle:
    Odhran:
    What a bloody awful piece of code!!

    They obviously never heard of XSL transforms either ... for shame!

    Yeah, because someone who would write something like this needs to be turned loose with XSLT...

    ... not saying XSLT is the wrong way, just this seems like the wrong person to attempt to use it!

    more like wrong person to attempt to use anything!

Leave a comment on “Catch and Release”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article