- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
if (thisPostException) throw new Exception("Post not Frist; 43456");
Admin
catch(Exception ex) { if(ex.Message.Contains("43456")) { Logger.Error("Secnod"); } }
Admin
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.
Admin
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.
Admin
LMFTFY:
Isn't it much better? ^^
Admin
Much better.
Admin
Probably heard around office: "I'm having a terrible time trying to get error number 888 implemented!"
Admin
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.
Admin
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!
Admin
"But all the unit tests pass!" Oh wait -- there aren't any unit tests either.
Admin
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.
Admin
I agree people sometimes get frenzied when they are presented with a bare error code.
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
ifstatements 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*
Admin
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.
Admin
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.
Admin
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!