• bogolese (unregistered)

    Universal Catch and Kill

  • (nodebb)

    If VB6 taught us anything, it's that if you don't see any error messages, then there must be no errors.

  • LZ79LRU (unregistered) in reply to DocMonster

    If you are using VB6 you have committed to the original error.

  • WTFGuy (unregistered)

    OTOH, if you are using .Net today but the code started as VB6 code and has been pastiche-modified ever since, you have committed "Normal USA-style 21st century devops".

  • Tim (unregistered) in reply to bogolese

    not only catch and kill; it ensures the function returns null, which leaves responsibility for error handling to the caller - that's about as far as you can get from an error handling framework

  • Tim (unregistered)

    in my experience the best strategy for handling errors is to have a single top-level error handler. Only catch specific errors lower down if you're expecting them and know how to recover

  • (nodebb)

    That method does consume a little bit of memory and CPU cycles. (Provided it's not optimized away at some point in the .NET pipeline.) I'd like to propose an alternative way to obtain the same result:

    for(int i = 0; i < 10000; ++i) { }
var buffer = new byte[4096];
  • supermagle (unregistered)

    Well, it does do one thing: Provide a common class with a single spot to place a breakpoint.

  • Brian (unregistered)

    Deferred execution with LINQ is great, but it can be misleading. There are two things here that make the ToList() necessary (although I won't make a judgment call on the correctness of the design). One is the error handling; errors are thrown where the query executes, which is not necessarily where it's written, so if you want to catch a LINQ error you have to actually run it. The other is the using - running a query on a disposed object is a very bad idea, so it needs to be executed inside the using scope.

    However, my preference would still be to return an IEnumerable from the function even if it's internally a list, just for the sake of cleanliness.

  • Abigail (unregistered)

    Probably some KPI which gives some incentive if the number of bugs is below a random threshold.

    And bugs which aren't logged don't count against the KPI.

  • (nodebb) in reply to supermagle

    This is simultaneously more and less valuable than it would have been if the error handling had been localised and correct.

    More: It does allow commonality of code, and it does allow breakpointing on any error.

    Less: It breakpoints on all errors, including the ones that aren't interesting, but also including the ones you didn't know where happening. (That might be a positive, of course.)

  • Randal L. Schwartz (github)

    An error-mishandling framework.

  • (nodebb) in reply to Steve_The_Cynic

    It breakpoints on all errors, including the ones that aren't interesting, but also including the ones you didn't know where happening. (That might be a positive, of course.)

    I hope you know that this has been a feature of Visual Studio for at least twenty years. https://stackoverflow.com/questions/116896/visual-studio-how-to-break-on-handled-exceptions

  • (nodebb)

    That handler does something: it swallows exceptions silently.

    That is rarely a good course of action.

  • Officer Johnny Holzkopf (unregistered) in reply to Ralf
    Comment held for moderation.
  • LZ79LRU (unregistered) in reply to Ralf

    Would you prefer if it spat them out and than complained and got angry you didn't warn it in time?

  • TheCPUWizard (unregistered)
    Comment held for moderation.
  • mitch (unregistered)
    Comment held for moderation.
  • varun (unregistered)
    Comment held for moderation.
  • (nodebb) in reply to supermagle

    Don't modern .Net debugging systems allow you to break when an exception is raised?

Leave a comment on “Universal Catch”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article