• Industrial Automation Engineer (unregistered)

    if (thisPostException) throw new Exception("Post not Frist; 43456");

  • (nodebb)

    catch(Exception ex) { if(ex.Message.Contains("43456")) { Logger.Error("Secnod"); } }

  • (nodebb)

    Classic case of people abusing exceptions for return messages.

    Spoiler: Exceptions are super expensive, generate lock states and even if none are thrown exception scopes are not free. Oh, and obviously for nearly every platform they are also low level OS constructs which have hooks for various monitoring services, which makes them even more expensive.

  • LZ79LRU (unregistered)

    As a general if not entirely universal rule I would say that if you have so many exceptions in your system that they have become a performance problem you have bigger things to worry about than performance.

  • (nodebb)

    LMFTFY:

    catch (Exception ex) when (ex.Message.Contains("8888"))
{
    ...
}
catch (Exception ex) when (ex.Message.Contains("1337"))
{
   ...
}

    Isn't it much better? ^^

  • (nodebb)

    It's better than:

    try { } catch {};

  • Balor64 (unregistered)

    I see the error codes have different lengths, and they're doing string comparisons instead of integer comparisons to check for the codes. I sure hope that doesn't cause any problems.

    if (ex.Message.Contains("12345"))
{
            ...
}
else if (ex.Message.Contains("123456"))
{
        ...
}

    Whoops.

  • LZ79LRU (unregistered) in reply to tom103

    Much better.

  • TS (unregistered)

    My objection to this is that it's using throw() as a synonym for goto. If you've identified an error condition here, handle it here (or by calling a function if it's more than a one-liner). The exception palaver adds no value.

  • (nodebb)

    Probably heard around office: "I'm having a terrible time trying to get error number 888 implemented!"

  • TheCPUWizard (unregistered) 
    try
    {
        var responseText = await streamTask;
        return responseText;
    }
    catch (HttpRequestException e) when (e.Message.Contains("301"))
    {
        return "Site Moved";
    }
    catch (HttpRequestException e) when (e.Message.Contains("404"))
    {
        return "Page Not Found";
    }
    catch (HttpRequestException e)
    {
        return e.Message;
    }
  • mitch (unregistered)

    This is absolutely horrible.

    Good look distinguishing your numerical error codes 33, 37, 133, 337 and 1337 using a substring search.

    Remember how error code 337 means "can't open file"? If you ever wanted to include the filename in the error message, your filename better does not include any part that might look like an error code.

  • Jeremy (unregistered) in reply to mitch

    'Good look distinguishing your numerical error codes 33, 37, 133, 337 and 1337 using a substring search'

    Better not check them in numerical order

  • (nodebb)

    This hurts me physically.

    This also has the wonderful effect that if any thing in the try block throws an exception that isn't one of the created ones that are being looked for, it will just continue processing leading to who knows what kinds of hard-to-reproduce behavior in the future. Wheee!

  • DrPepper (unregistered)

    "But all the unit tests pass!" Oh wait -- there aren't any unit tests either.

  • LZ79LRU (unregistered) in reply to mitch

    To be fair we don't know what is the root cause of the handlers. The code is too heavily obfuscated/anonymized for us to know that.

    For all we know these exceptions might actually be generic exceptions coming from a modern wrapper built around some external interface that returns error codes. And those are still in the wild and operating happily. Examples include but are not limited to HTTP, winsock and the FIX engine to name a few.

    And in those situations the best you can do is filter by error code and translate it into something more user frenziedly by using the manual as a lookup table.

    And while using constants for the numbers might sound like a no brainer it isn't always the case. After all, why bother defining constants if the text description of what is going on is logged right inside the switch clauses. Especially if you are building a master error handler that wraps around the whole external system as is often the case.

  • löchlein deluxe (unregistered)

    Eh… I can kinda sorta see that if you're in the middle of bug hunting and need a Throw-away exception (:sunglasses:) because your problem is further upstream and it's really supposed to be a CantHappenException. It's very much the System.err.println() approach, though. And on top of it, then you got interrupted and forgot and so it went into the repo.

  • (nodebb) in reply to LZ79LRU

    something more user frenziedly

    I agree people sometimes get frenzied when they are presented with a bare error code.

    For all we know these exceptions might actually be generic exceptions coming from a modern wrapper built around some external interface that returns error codes

    Well we know they are being thrown when something bad happens or something else bad happens. We are given the sites where these exceptions are thrown. The implication is that the person who wrote the code has full control over what exception is actually thrown.

    However, I don't think the if statements checking the content in the message is the worst WTF here. Every other possible exception is silently thrown away. I am not familiar with exception handling in C# but in Java this code would result in even runtime exceptions like null pointer exceptions and array bonds exceptions being ignored. This is a Bad Thing.

    Addendum 2023-03-31 06:20: bounds*

  • LZ79LRU (unregistered)

    That was supposed to be friendly. Dam spell checker.

    Anyway, if what you say is true and all exceptions are ignored that would be bad. But we can't blanket assume that from the code. And even if that is the case it could just be a mistake made by someone who intended only to handle their specific custom exceptions.

    And for those there are plenty of situations where log and/or handle and forget is appropriate.

  • no really no (unregistered) in reply to LZ79LRU

    the code is not at all obfuscated. that is pure pain. even assuming the scenario described in your post, the solution would be plain wrong. the code detects the error situation, then throws a generic message with a special error message to later on catch the generic exception caused by itself and by "parsing" the error message trying to distinguish between the different potential error scenarios. the root issue is using the generic exception and misusing the error message to detect the actual exception. for exactly that purpose usage of none generic exceptions are the one and only clean way to go.

  • LZ79LRU (unregistered)

    Mind you, I am not saying that every case of this is sane or even that this particular case is necessarily so. Indeed, it likely is not given the overall context provided in the actual article.

    All I am saying is that I can see real world applications where such code would in fact be both sane, useful and an actually decent way to go about things.

  • Strahd Ivarius (unregistered)

    As the saying goes: take a piece of code with an issue, add regular exceptions, and now you have a piece of code with 2 issues at a minimum.

    oh, I meant regular expressions, sorry...

  • Kythyria (unregistered) in reply to LZ79LRU

    If you want to use an exception to wrap an error code without a gazillion subclasses, the sane way is to subclass and add a field/property containing the error code. You could even put the table of code -> message in a getMessage() method or something!

  • LZ79LRU (unregistered)

    That's what he did though. He used the message property of the error object. That's the standard C# way to pass error messages.

Leave a comment on “Exceptional Messages”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article