23 comments

0

Always, always have error protection in whatever you're coding. Fuck even if it's fucking Excel always wrap everything in a mighty condom of IFERROR(). Always expect the unexpected when you're working with software. No matter how brilliant a code is, they have logical mental blocks which cause errors. You infect code with bugs as you write it if you are at all human. Expect a third state. It's what created our universe.

0
0

Not necessarily. You need to understand how exception handling is supposed to be implemented and temper that with the kinds of exceptions you expect.

For example, if I have a number class

Number num = new Number("d");

You need a way to handle that. Depending on how your constructor is set up (including any inheritance), you may decide that D is a valid numeric character (along with E or M, for example).

Generally speaking, your lower level objects should not care about exception handling except in instances where you really need to return a status of the current state of affairs. For example, a WebAPI should probably return some kind of status or exception instead of "200 OK".

A good general rule of thumb: Exception handling should be only as far down as needed. Said another way: Exceptions should be thrown as far up the stack of objects as reasonably possible.

It doesn't make sense for your POCO to handle and throw an exception from the database class it sits on top of. Let the database class handle that and it will bubble up the chain. It's not the POCO's responsibility to handle database exceptions. Otherwise, you're going to run yourself ragged trying to handle every possible exception point.

The other reasonable place to handle exceptions is anywhere a user might see the IIS error screen. You know which one that is... the scary screen with the yellow background and big red scary letters. Users flip out and thing they broke the server. You want to handle those and let the user know something was up.

0

I would say no. Most of the above could be refactored to contain a TryRead,TryParse or error handled method instead. Just like MS will suggest using Guid.TryParse over new Guid(string).

0

Exceptions are never a good thing.

0

NEVER!

A constructor should always be sometime that is fast and cannot goes wrong. It is one of the thew methods that should be 100% bug free and not lose time.

The whole reason why you need a constructor is to set up a predictable environment that is fully functional and not partially initialized.

Also avoid exceptions at all costs. It should only happen when something is very wrong, and not part of your normal operation. It should only happen once every million years of your code running. Exceptions cause a giant stack trace with worthless information no one understands.

0

LOL I kind of suspected this submission would get some curmudgeon responses!

I actually giggle when my v/programming submissions get downvoted. I love my math subs and I think the people in them are great, but I get a special sort of joy from submitting to this sub. I do try to push the content heavy CompSci, more than top-tens, memes, and fluff. I am pretty sure it's appreciated, judging by the votes in a low-volume sub. But, still, the curmudgeons crack me up.

I actually look forward to, read, and even learn from the responses I get. While I can program a little, and have even programmed professionally - albeit a lifetime ago, I'd never say I'm a programmer. I'm not. I actually hate it - to actually do it. On the other hand, I like to read code and I don't mind changing code. I also like to read about code and to keep up with what's going on with the programming languages.

It amuses me to no end to see the popularity of Java and JavaScript (and yes, I know they're very different languages). See, I've seen all the complaints and comments - since the 90s. I've seen haters become fans. I've seen them both become standards. I've seen the owner of Java change. I've seen the fretting and the rise of OpenJDK. I've seen the millions of JavaScript frameworks come and go. I've watched y'all bitch about them - while some gushed over them. I've seen them both become reasonably fast and relatively secure - potentially.

I do enjoy programmers. I'm pretty sure you're all born grumpy old men. Even women programmers are born grumpy old men! ;-)

0

In programming the majority are actually very bad. They are good a one line SQL queries, they are good at using enterprise libraries and design patterns. They are good at scripting code. But their mindset is stuck to only what others have told them and they have no clue that there are other and way more better ways to do it.

I recently discovered that it is especially the younger generation that gets so easily manipulated in creating modern crappy code nowadays. I am seeing how very talented developers suddenly start to create worse crap that they were fixing in the first place.

It is upsetting because the last few weeks I am repairing their stuff that they started but sudden lost interest in. Now they started with other stuff that is even worse. It is amazing how a team of talented people gets sucked into this modern style of applications that are ergonomic the worst. The sad part of all this is that this will become a wasted generation. In 10 years from now they either burn up or get into a depression. While I will keep on developing.

0

Yeah, it's not a job I'd even remotely dream of accepting today. Not a chance.

I do like to read code from other people - and I like to learn about it. Sometimes I'll tweak something and submit a patch, but I haven't done any real programming in ages. I hate to admit this, but I'm also a bit fond of PHP. I have a bit of a home setup here that has a web interface and it works surprisingly well.

0

I think you may like TensorFlow. It is basically the ASP.NET framework to create HTML but this library spits out neural network execution "graphs" that then gets executed as vector math.

The cool thing about these TensorFlow graphs is that you construct them as you want. Similar like panels in HTML pages. You are still a programmer that crates these functions. And you decide how to combine these functions.

0

LOL I've been looking at TensorFlow and AI, lately. I'm thinking about buying a few books and seeing where that takes me.

0

TensorFlow Machine Learning Cookbook is for me the best one so far.

It doesn't delve too deep into the mathematics, it actually explains what you can do with it. The hardest part is actually getting it installed and functional. In that they still need some coding to do to make it user friendly.

0

I'll add it to my list. I'm going to order a few of them. If nothing else, they'll make fine additions to my library.

0

When an exception is thrown in your code, it basically means: You suck at coding!

Real developers will have an error reporting mechanism that gives meaningful information in a user friendly way that does not require a stack trace to go through nor log files.

0

Now you're just karma whoring. You know damned well I'm gonna vote that up.

1

The truth must be said, even if I risk getting upvotes!

0

I would say no in C# because it is a typed language. If you are permitted by the compiler to call the constructor it should run without issues. Now JavaScript on the other hand, yes, yes constructors should throw errors.

0

Another question you may ask is if it is a good idea to throw an exception in a property?

0

Elaborate, if you don't mind?

1

I have seen a lot of developers getting confused when to use a method and when to use a property. Although I avoid using exceptions because they cause more problems than it solves, I do know that sometimes an exception should be thrown.

The thing is that more and more properties gets loaded with code that should be included in a method only, it is tempting to start triggering an exception if the value that you load is out of bounds.

So the discussion could be if it is OK to have exceptions inside a property method or not?

0

That makes sense, thanks!

0

Write shit that doesn't break and if it does, log it yourself. I have the same exception handling and error reporting library in all of my software at work. One DLL included in every project and I know what to expect when shit hits the fan.

-1