• (disco)

    Potential for Exceptionceptioneoption?

  • (disco)

    I'll just leave this here...

    https://msdn.microsoft.com/en-us/library/System.ApplicationException

    You should derive custom exceptions from the Exception class rather than the ApplicationException class. You should not throw an ApplicationException exception in your code, and you should not catch an ApplicationException exception unless you intend to re-throw the original exception.

    And this...

    http://stackoverflow.com/a/5685943/1386111

    System.ApplicationException is a class that should not be part of the .NET Framework. The original idea was that classes derived from SystemException would indicate exceptions thrown from the CLR (or system) itself, whereas non-CLR exceptions would be derived from ApplicationException. However, a lot of exception classes didn't follow this pattern. For example, TargetInvocationException (which is thrown by the CLR) is derived from ApplicationException. So, the ApplicationException class lost all meaning. The reason to derive from this base class is to allow some code higher up the call stack to catch the base class. It was no longer possible to catch all application exceptions.

  • (disco) in reply to Tsaukpaetra
    Tsaukpaetra:
    Potential for Exceptionceptioneoption?

    No, but the exception you throw might not be the exception you expected to throw. Because.

  • (disco) in reply to dkf

    Well you only need to overload the SendEmail function (I am not at all familiar with .net, so bear with me) with a custom one which do use your own mandatory exception(inception) class..... Booom :smile:

  • (disco)

    An exceptional display in FF 40.0.3:

    [image]

    No problems in IE11 though; anyone else seeing this?

    Edit: Damnit - Ignore this, the problem was due to cr*ppy FF cache handling. Post not deleted to retain context for @RFoxmich's response.

  • (disco)

    http://pre04.deviantart.net/d429/th/pre/f/2013/163/5/9/ring2_by_badriel-d68re7u.png

    Throw it into the fiery depths of the crack of doom.

  • (disco)

    So you make sure that at least the error is logged, even if the application blows up or silently swallows the exception. Not a real :wtf: IMHO.

  • (disco) in reply to RFoxmich
    RFoxmich:
    crack of doom

    Why are you stuffing a ring in someones butt crack?

  • (disco)

    Thank you Remy, exceptional article.

  • (disco)

    I have an almost identical setup and class except it logs rather than sending emails.

    The origin of that was that there were several modules that could be pieced together in a variety of ways that would encounter various error conditions and would eventually output to a variety of frontends.

    Certain error states would preferably cause a variety of different behaviours once caught at the top. With some potentially deep call stacks the only convenient way to send error information back up to a scope that can handle it is to use custom exceptions. Anything else would require the use of globals/parent variables or special return types which would mean modifications to every method/class in the call trace up to the original caller. I have seen these kind of solutions in practice and they always cause more harm than good.

    In some cases this could have been avoided with checks earlier on if it were not a legacy codebase and in other cases this was more complicated. The problem was that this was not a library written entirely from the ground up but rather had to integrate into a pre-existing codebase. The exceptions were hacked onto it as an afterthought to make libraries more portable. The time constraints, program flow design and other aspects of the legacy codebase made it difficult to implement proper handlers. The net result of this was that rather than having an exception type that would imply the action to take once it reached the top most handler would be to log it, the class would log errors in the constructor. The other solution is to use the publisher-subscriber pattern but that doesn't solve the problem with return types that exceptions are meant to solve. When it comes to exceptions even with good handling you can still have a lot of bootstrap problems. The base structure of the code has to be designed to handle this.

    This is something I considered refactoring but as it actually works really well apart from some implementation ugliness it's a bit of a case of YAGNI or don't fix what isn't broken. Ultimately the reason it is like that is because of the structure of the rest of the code in the application so it's a case of if you fix this, you have to fix everything which means a full rewrite.

    Normally if you see this anti-pattern, it is because it wasn't practical to put the handling anywhere else. The WTF for me is that this was written presumably from scratch as a standalone library. That leaves little excuse for not providing handlers with the exceptions.

  • (disco)

    A while back they made a cleanup pass through Windows XP. They found a very similar situation, where some low-level code in the kernel was calling up to do some HTTP stuff, like a dozen levels above that layer.

  • (disco) in reply to RFoxmich

    At least it was photographed on a wooden table :^)

  • (disco) in reply to isthisunique

    Sometimes, as developers, we're forced to do things we're not proud of due to ridiculous time constraints or arbitrary requirements handed down from people who have no clue as to what they are really asking for. That said, they should have done a few things differently:

    1. Loading values from the config file could have been done in a singleton instance so that it only happened once per application domain. That way you're not initializing variables, reserving memory space and parsing config files every time something goes wrong.
    2. You use try/catch to make sure that what you're doing can't possibly throw exceptions that "hide" another exception.
    3. Document the hell out of why you had to do such a "bad" thing. That way, when it gets discovered by another competent developer, you will get their sympathy rather than their wrath.
    4. And, if it gets found by an incompetent developer, they (hopefully) won't think it's "a great idea" and replicate it elsewhere with even worse code.
  • (disco) in reply to tenshino
    tenshino:
    1. Loading values from the config file could have been done in a singleton instance so that it only happened once per application domain. That way you're not initializing variables, reserving memory space and parsing config files every time something goes wrong. 2. You use try/catch to make sure that what you're doing can't possibly throw exceptions that "hide" another exception. 3. Document the hell out of why you had to do such a "bad" thing. That way, when it gets discovered by another competent developer, you will get their sympathy rather than their wrath. 4. And, if it gets found by an incompetent developer, they (hopefully) won't think it's "a great idea" and replicate it elsewhere with even worse code.

    I'm not sure how much I agree. At first glance in principle it looks valid but then the real world strikes...

    1. Might be premature optimisation.
    2. It might work or this could add even more quirks depending how the rest of the code is laid out. It can lead to premature fixing which might introduce yet more errors.
    3. If the developers didn't have time to code it properly, they wont have time to document it properly.
    4. Incompetent developers can't be helped anyway and shouldn't be the burden of competent developers. They have to step up, we shouldn't have to step down.

    The worst possible thing that could happen is if SendEmail somehow triggered another BaseException, after sending the email. That's the one that wants to behave like a singleton. Some people improve this by sending the encrypted error as output (youtube).

  • (disco) in reply to tenshino
    tenshino:
    4­. And, ifwhen it gets found by an incompetent developer,
    FTFY
    tenshino:
    they (hopefully) won't think it's "a great idea"

    :rofl: Ever the optimist, huh? Even comments like // DO NOT EVER FUCKING DO THIS!!! won't deter the truly incompetent.

  • (disco)

    every application needed to make use of every component in them, otherwise why have the libraries at all?

    "Don't forget to quote from our institute library in your thesis - what for would we have it otherwise? And make sure you quote from every single one of the 63,187 books."

  • (disco) in reply to isthisunique
    isthisunique:
    Might be premature optimisation.
    The point of loading the config file once isn't for optimisation, it's for safety. When you're in an exception state, you want to do as few things as possible that have the potential to re-trigger the exception (or possibly an entirely new one). Any file access, memory allocation, etc. that you can take out of the exception logic means less chance that things will go even more pear-shaped when you try to handle the exception.
  • (disco) in reply to Scarlet_Manuka

    Yep exactly.

    That is why I only do logging/emailing of errors in the catch, there you are (a bit at least) sure that things will not get much worse if the logging/emailing system goes belly up...

  • (disco) in reply to HardwareGeek
    HardwareGeek:
    won't deter the truly incompetent

    "aggressively incompetent"

  • (disco) in reply to No_1
  • (disco) in reply to ben_lubar

    I thought it was clear and obvious that I was actually referring to this.

    Filed under: Next time I'll post a link.

  • (disco)

    Definitely a Few WTF's in the implementation. But the concept of having a logging point at the creation of the exception is potentially reasonable, if not ideal.

    Most developers [that program in .NET and use Visual Studio - all others can ignore the technobabble] have at some point used Debug->Exceptions and enabled "Break on Throw" rather than (the default) "Break on Un-Caught" to get further insight.

    Now if we look at the lifecycle there is...

    1. Exception Class Instance Created
    2. Instance Thrown
    3. Instance Caught (optional)
    4. Instance Never Caught and BOOM

    Writing logging code for #3 is trivial (and the most common). Fewer than 10% (based on many interviews given) of Senior developers know that #2 and #4 can be done - even fewer know how; only ONE developer interviewed for a "regular" position has gotten this right in a decade!

    So it is natural that there is a focus by many to resort to #1. The real fun start when you then find...

    var ex = new MyLoggedException(...);
// stuff
if (condition) throw ex;

    The logging occurs even if the exception is NOT thrown....

  • (disco) in reply to No_1

    Nevermind Ben. He just got old enough to be allowed to use foul language.

  • (disco) in reply to Scarlet_Manuka

    The point of loading the config file once isn't for optimisation, it's for safety. When you're in an exception state, you want to do as few things as possible that have the potential to re-trigger the exception (or possibly an entirely new one). Any file access, memory allocation, etc. that you can take out of the exception logic means less chance that things will go even more pear-shaped when you try to handle the exception.

    I'm aware of that but it is not what he advertised it for. I'm sceptical loading configuration would fail that often and that is more of a monkey patch than a real solution. The biggest WTFs are when such systems are continually monkey patched rather than taken back to the drawing board. The email handling is a far bigger problem. It's a mailbomb waiting to go off.

  • (disco) in reply to isthisunique

    If you were going to go back and refactor this, I would definitely recommend doing things differently than this implementation. I can think of several ways to accomplish this same thing that don't involve sending emails from a class constructor ::shudder::

  • (disco) in reply to tenshino
    tenshino:
    I can think of several ways to accomplish this same thing that don't involve sending emails from a class constructor

    You could send it from the Finalize method… :tropical_fish:

  • (disco) in reply to dkf

    I think you're still better off building some static class that contains a static method that accepts the exception as an argument. Then, anywhere you want an email sent, you just add the method call to the catch, passing the exception. That method then formats and sends your email, with its own error handling and secondary logging mechanism in case it's not able to send the email. Then, it's just a matter of getting enough people with a basic understanding of syntax and the ability to use Copy/Paste to add in those calls. For any exceptions that don't have a Try/Catch, there's the Global.asax, or Application.OnUnhandled (I think that's the method name. Haven't done WinForms apps in a while)

  • (disco) in reply to tenshino
    tenshino:
    Then, anywhere you want an email sent, you just add the method call to the catch, passing the exception.

    Surely what you do is you pass a lambda (or whatever the right C# name for those things is) to the method which calls the function and then traps any problems and sends emails and logs them in databases and so on. Easy!<in a Doing It Wrong way that is

  • (disco) in reply to isthisunique

    I just remembered: you mentioned the "mail bomb". I have for years run code that will send email notifications for applications. Much the setup I described here: https://what.thedailywtf.com/t/taking-exception/51251/29

    I can trigger emails from inside a Catch block, but I also have it set to notify me of all unhandled exceptions via the global.asax. Often, I know when the SQL or GIS box is offline (or having problems) before the network guys do. I also get notified when "weird" requests come in, or 404 errors get thrown. Sometimes that can get annoying, but I use exchange rules to manage most of it.

    A couple of years back, I was working for a company that did paperwork processing for banks. I'm sitting at home one night (about 9pm), playing Xbox, when I glance down at my trusty (not really) Blackberry Bold and notice that I have over 7000 new emails. My first thought was to laugh and wonder what kind of drugs my Blackberry was smoking this time. Then I noticed the number was increasing. Rapidly. The Blackberry was so busy downloading emails, I could barely get it to respond. So, I fired up the VPN and connected to my workstation at the office. That's when I saw my inbox: over 37,000 new emails and counting.

    I looked at a couple of them, and it was obviously someone trying to find a querystring or SQL injection vulnerability in the site. I tried calling my boss, but got no answer, so I immediately started typing an email to my boss, and every person I know of in the network team. In the middle of typing, I got disconnected from my workstation. Kept trying to get back in, but it just kept telling me that there was no response.

    So now I'm really starting to freak out, thinking that someone had actually gotten in. I managed to type up an SMS message on my Blackberry to my boss that just said "Hackers in server. Phone not working. Call my personal cell." No response.

    The next morning, I walked in the door and headed straight for my bosses office. I found out that one of our customers had decided to run an intrusion test suite against the site during the night. I had ended up with over 45,000 new emails. I asked them to let me know if future, so that I could disable the email notification system in the web.config.

    But nobody had any idea why I had been kicked out of my workstation during the middle of it all.

    I found out later that one of the pieces of software that the accounting team used only allowed a single user to be in the system at a time. Apparently, their MO when someone was in the office by themselves and couldn't get in was to go around and hold the power button on every other PC in accounting, powering them down. That night, one of the accountants had simply gone one cubical too far down and happened to power down my PC right at that moment.

    There's probably a few RWTF's in there ;)

  • (disco) in reply to tenshino
    tenshino:
    go around and hold the power button on every other PC

    This, kind entities, is why I never walk away from my PC without saving everything. Also why I unplugged the power LED cable from the motherboard.

  • (disco) in reply to isthisunique
    isthisunique:
    > The point of loading the config file once isn't for optimisation, it's for safety.

    I'm aware of that but it is not what he advertised it for.

    Pardon? @tenshino explicitly said the point of this was

    tenshino:
    That way you're not initializing variables, reserving memory space and parsing config files every time something goes wrong.
    Not optimisation, rather avoiding these operations when you're in a bad state.
    I'm sceptical loading configuration would fail that often
    It seems pretty reasonable to me. For instance, you have a memory leak which you don't notice until you get an out of memory error. Then you go to load your config file and try to allocate a buffer to read from it, and oh, that failed because you're out of memory.
    The biggest WTFs are when such systems are continually monkey patched rather than taken back to the drawing board. The email handling is a far bigger problem. It's a mailbomb waiting to go off.
    No argument there.
  • (disco) in reply to TheCPUWizard
    TheCPUWizard:
    1) Exception Class Instance Created2) Instance Thrown3) Instance Caught (optional)4) Instance Never Caught and BOOM

    Writing logging code for #3 is trivial (and the most common). Fewer than 10% (based on many interviews given) of Senior developers know that #2 and #4 can be done - even fewer know how; only ONE developer interviewed for a "regular" position has gotten this right in a decade!

    Ok, now you got me interested even though I'm looking in from Java...

    Number 4 seems to be done by registering an event handler on a special delegate (e.g. http://www.codeproject.com/Articles/2949/Managing-Unhandled-Exceptions-in-NET) which you can do thread-by-thread in Java as well, but number 2 is something I've never seen being done in Java.

    My Google-fu indicates that it can be done using the AppDomain.FirstChanceException event, does it work all that well?

  • (disco) in reply to JBert
    JBert:
    but number 2 is something I've never seen being done in Java

    You might have to use an AOP interceptor. Ugly.

  • (disco) in reply to TheCPUWizard
    TheCPUWizard:
    Fewer than 10% (based on many interviews given) of Senior developers know that #2 and #4 can be done - even fewer know how;

    Huh. I thought Googling for "log all unhandled exceptions" would cover at least #4.

    Didn't know you can also hook to first-chance, but that seems to be of pretty little use - a caught exception might be a nigh-fatal error, a simple condition, or even a part of normal program operation (say, you have something that needs custom parsing and the library doesn't expose TryParse).

  • (disco) in reply to JBert
    JBert:
    My Google-fu indicates that it can be done using the AppDomain.FirstChanceException event, does it work all that well?

    Try checking the "break on first-chance" checkbox in VS and see how much time you need for it to get on your nerves. The estimate is about 20 to 30 minutes, possibly less depending on the libraries used.

    Point is, it's useful when you know what you're looking for (say, a library gives you a nondescript "An error has occured" ThatLibraryException, and you try to investigate), and totally annoying otherwise.

  • (disco) in reply to JBert
    JBert:
    Ok, now you got me interested

    Ding Ding Ding we have a winner.

  • (disco) in reply to Maciejasjmj
    Maciejasjmj:
    Try checking the "break on first-chance" checkbox in VS and see how much time you need for it to get on your nerves. The estimate is about 20 to 30 minutes, possibly less depending on the libraries used

    Not in Visual Studio....when your code is running in production.

  • (disco) in reply to Tsaukpaetra

    If it's a metal power button, figuring out a way to attach it to a high-voltage input line would also prevent hostile entities from attempting to press it. More than once.

  • (disco) in reply to sloosecannon

    Oh that's easy, just reverse ground and live. Most cases have rubber feet, right?

Leave a comment on “Taking Exception”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article