• (nodebb)

    The frist thing that makes me uneasy about this code is the implication that it is Global.Insert(string,string). "Global" ??? and what is it inserting? (Yeah, I know, two strings, but why would you insert them in something global?)

    Addendum 2024-04-03 06:58: Note that I read Remy's "Easy Reader Version" after posting the above...

  • Michael R (unregistered) 
    try
{
/* ... some important code ... */
} catch (NotFristException exception) {
        Global.Insert("App.GetSettings;", exception.Message);
}
  • Jonathan (unregistered)

    Looks like a case of paid by the line.

  • TheCPUWizard (unregistered)

    Allows for easy setting of breakpoints on specific exception types without modification or knowing how to use conditional breakpoints.

  • (nodebb)

    No. No. No. This is just a stub (to be copied and pasted everywhere in the code) to handle any type of exception that might occur. If you really need the OutOfMemory exception, you already have the template to 'Insert' the appropriate string (preferably hard-coded.)

  • Sauron (unregistered)

    Maybe an OutOfMemoryException should be thrown every time a dev forgets common sense.

  • (nodebb)

    What are the chances that, if you have just thrown an OutOfMemory exception, inserting something into something else will trigger another OutOfMemory exception?

  • (nodebb) in reply to jeremypnet

    What are the chances that, if you have just thrown an OutOfMemory exception, inserting something into something else will trigger another OutOfMemory exception?

    Better than average, I'd say. (OK, yes, it's possible to avoid that problem by preallocating the container used by Global.Insert to have empty elements for its maximum capacity, but do you think the sort of programmers who'd write something like this would think of such a thing?)

  • Sauron (unregistered) in reply to jeremypnet

    It depends. There are 2 typical causes for the exception: https://learn.microsoft.com/en-us/dotnet/api/system.outofmemoryexception?view=net-8.0

    If you're just doing bad stuffs with a StringBuilder object, then maybe the insertion won't cause another OutOfMemoryException.

    If the computer does run out of memory, then it's unclear. The documentation says that you should handle it like something unrecoverable. But on the other hand, it also says that the system ran out of contiguous virtual address space just for a particular operation, so it's not clear if there could still be enough contiguous virtual address space for stuffs like the insertion.

  • Klimax (unregistered) in reply to Steve_The_Cynic

    The least bad case is, Global is short for GlobalLogging or something like that...

  • (nodebb)

    At first glance I thought that's the usual Java checked exception hell. But then I realized that there's an NullReferenceException instead of a NullPointerException, and now I'm pretty sure it was a Java developer importing the checked exception hell.

  • (nodebb) in reply to jeremypnet

    Ironically, slim.

    Memory structures in .net are generally based on preallocated arrays and if you have dynamic growth, then a second array with additional headroom will replace the first one after the content is copied.

    In other words, if you don't specifically restrict the capacity of dynamic collections to a specific exact value at initialization or exactly fill the collection up to the current capacity, there's a big chance that you still have room left for multiple additional additions.

    Plus, keep in mind, an out of memory failure is often just a temporary failure. Modern OS have plenty of room to recover from temporary memory shortages; so an out of memory issue can turn to a non-issue a few microseconds later. It's actually super hard to ran out of memory permanently these days if you are not really, really forcing the issue.

  • (nodebb)

    I don't find "Global" here evil--that's no doubt a systemwide logging system. When they map to real world resources (say, a log file) you end up with something approximating a global no matter what you do.

  • xtal256 (unregistered)

    "Well, I guess that if they ever need to add different code paths, they're halfway there."

    I once worked with a fairly smart developer who unironically thought this was a good idea. Not specifically for exceptions but the idea of duplicating many lines just in case you ever need to change one to be different.

  • NextRelease (unregistered)

    "Modern OS have plenty of room to recover from temporary memory shortages; so an out of memory issue can turn to a non-issue a few microseconds later. It's actually super hard to ran out of memory permanently these days if you are not really, really forcing the issue." At least in java this is not the case. When you get an OOM, it means the JVM has tried really hard to obtain that extra memory needed, and failed miserably, and there is nothing you could reasonably do to prevent everything from crashing and burning. It is actually an antipattern to try and catch that particular exception (and you might expect a broken wrist if you still attempt to do it).

  • Nick (unregistered)

    I’m remembering back from the dark ages that Java 1.4 (or maybe it was 1.2) didn’t have any way to catch multiple exceptions in the same block. These days, you can separate the exception types with a pipe symbol, but I don’t think that was available originally.

    Therefore, in that version of Java, this is the only way to catch a specific set of typed exceptions that might be thrown. Sure, you could use a generic Exception - but then you’ll be catching other exception types that you might not have wanted to handle this way. If there’s no super class common to the exception types that you want to catch, this is your only solution.

    So, I guess TRWTF is old versions of Java, that have since been changed, and old, perfectly working code, that hasn’t been updated to the newest standard yet…

  • Álvaro González (github)

    Am I the only one to think that the original developer just didn't know how to catch all exceptions?

  • (author)

    wrt Nick's question, are any of those caught exceptions NOT subclasses of Exception (caught by the final stanza)?

  • (nodebb) in reply to NextRelease

    Keep in mind, this is .net code, not Java code. Those shortcomings of Java don't apply with a natively compiled language like C#, because there was never a VM (or whatever you want to call the Java interpreter).

    In .net it is also an anti-pattern to catch an exception if you can't handle it. The reason is pretty simple, because C# is a natively compiled language the compiler generates assembly code using native exception handling APIs. And those are all but free, even if you don't throw an exception. So generally you should handle exceptions as soon as possible or just let them escalate up the call stack until someone can handle them. On the very top you can finally have a global exception scope, which gets the exception and logs it before failing; cause if you don't handle an exception in the first place, there's no need to log it - after all exception have stack traces in .net; you know exactly where it happened and packing an exception into an other exception while doing nothing else, is also considered an anti-pattern.

  • Medinoc (unregistered) in reply to Sauron

    There used to be a third main reason back when .NET still supported GDI+: Opening a corrupt image would throw OutOfMemoryException.

Leave a comment on “Gotta Catch 'Em All”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article