Personal computing discussed

Moderators: SecretSquirrel, just brew it!

 
derFunkenstein
Gold subscriber
Gerbil God
Topic Author
Posts: 24512
Joined: Fri Feb 21, 2003 9:13 pm
Location: Comin' to you directly from the Mothership

Better to throw exceptions or return null?

Wed Feb 28, 2018 11:26 pm

OK so in my Java class this semester, we've been re-implementing classes from the Java Class Library in our own custom classes in order to get a better feel for how some of these things work. I'm paired on lab assignments with a cool dude but he has a weird way of going about things. For example, we're doing Linked Lists time out. We made a Generic class Node:

public class Node<E> {
    E element;
    Node<E> Next;       
    public Node(E e) {
        element = e;       
    }
}


and then implemented the LinkedList using pointers. It was really quite fun.

But my lab partner does things differently than I do, and we didn't really come to an agreement as to the "right" way to do things. When we started implementing methods, he wanted invalid states to throw exceptions, where I wanted to return values that would indicate error states.

Like a getIndex(E e) method that returned -1 if e was not in the list, or a getValue(int index) method that returned null if the index was invalid (and then obviously check for getValue(index) == null or getIndex >= 0 before proceeding).

He wanted to throw NullPointerException or IndexOutOfBounds and wrap basically everything that you do with the LinkedList in a try/catch block. My understanding is that try/catch is kind of expensive.

In the end, we submitted an in-class lab assignment that used all this try/catch nonsense because I am quick to concede and doubt myself when faced with opposition and I'm not 100% confident, but when I extend it for my own assignment I'll refactor it. :lol: So what say you, wise developers of the TR forums? What's the "right" way to go about it?
I do not understand what I do. For what I want to do I do not do, but what I hate I do.
 
Redocbew
Gold subscriber
Gerbil Jedi
Posts: 1671
Joined: Sat Mar 15, 2014 11:44 am

Re: Better to throw exceptions or return null?

Wed Feb 28, 2018 11:43 pm

An exception is an event which disrupts the flow of control in your program. If you're looking for something that might be in your list, but isn't, then I don't think I'd code that as an exception. If you're looking for something which should be in your list, and it's not, then that's when you raise a flag that something went wrong. I'd say the example of a timeout is a good place to use an exception. Maybe the data being requested is super important and the program can't continue as planned without it, or maybe not. Either way, there should be some kind of notification to the code making the request that there may be a problem. Using an IndexOutOfBounds exception makes more sense to me in this case than using a NullPointerException. Since you're passing an index in it'd be weird to get an exception back about a pointer.

I try to stay away from large try-catch blocks in general, because the more stuff you "try" the less specific your "catch" can be on what you do about it. Sometimes you can mitigate that by adding multiple catch blocks, but if I can I'll usually break it up just to make things clearer.
Do not meddle in the affairs of archers, for they are subtle and you won't hear them coming.
 
derFunkenstein
Gold subscriber
Gerbil God
Topic Author
Posts: 24512
Joined: Fri Feb 21, 2003 9:13 pm
Location: Comin' to you directly from the Mothership

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 12:17 am

Sorry, that nul pointer exception would be instead of just returning null. The general idea being that I am checking conditions instead of wrapping in a try/catch is the important part.

What you say makes sense. At work I was taught to use as few try/catches as possible. Mostly in file system operations, network tasks, and parses. Anything that could be null might add well just do a null check, for example. But that's all .net rather than Java.

I hear you on the index thing though. Just about everything throws out of bounds exceptions on those.
I do not understand what I do. For what I want to do I do not do, but what I hate I do.
 
Redocbew
Gold subscriber
Gerbil Jedi
Posts: 1671
Joined: Sat Mar 15, 2014 11:44 am

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 12:22 am

If you control both sides of the call, then you can really do whatever you want. Where exceptions become important is when that is no longer the case. Just imagine if every standard library from Java or C# had a different way of notifying you of a problem. :o
Do not meddle in the affairs of archers, for they are subtle and you won't hear them coming.
 
Duct Tape Dude
Gerbil Elite
Posts: 700
Joined: Thu May 02, 2013 12:37 pm

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 12:28 am

Redocbew wrote:
If you control both sides of the call, then you can really do whatever you want. Where exceptions become important is when that is no longer the case. Just imagine if every standard library from Java or C# had a different way of notifying you of a problem. :o

Agreed. Java tends to be pretty exception-friendly. I've run into problems when using drivers in node.js for Java components (Kafka, Cassandra) because in Java world you throw an exception and can expect the caller to catch it, whereas in JS world you typically use callbacks/promises/events that use a function to return an error object. The drivers, written for a node environment, insist on throwing exceptions sometimes, killing the entire application. It's maddening.

derFunk, whatever you do, keep it consistent. Since your code is all synchronous you can do either one. Should you ever run into async code you should respect the language/framework's standard error conventions.
 
derFunkenstein
Gold subscriber
Gerbil God
Topic Author
Posts: 24512
Joined: Fri Feb 21, 2003 9:13 pm
Location: Comin' to you directly from the Mothership

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 1:46 am

Redocbew wrote:
If you control both sides of the call, then you can really do whatever you want. Where exceptions become important is when that is no longer the case. Just imagine if every standard library from Java or C# had a different way of notifying you of a problem. :o


Duct Tape Dude wrote:
derFunk, whatever you do, keep it consistent. Since your code is all synchronous you can do either one. Should you ever run into async code you should respect the language/framework's standard error conventions.


I think both of you probably hit on why I was taught as I was. In C# collections (which is so much of what I deal with) you can check if the collection is null and check whatever else you want all in one line. I'm sure some of this applies to Java, too, but I'm using to doing stuff like null conditionals:

if(myGenericList?.Count > 0)

that's totally, 100% safe. Meanwhile, List<T>.IndexOf returns -1 for objects not in the list (same for Collection<T>). So I'm just applying the .NET way of thinking to my Java programs, apparently. :lol:
I do not understand what I do. For what I want to do I do not do, but what I hate I do.
 
synthtel2
Gerbil Elite
Posts: 776
Joined: Mon Nov 16, 2015 10:30 am

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 1:54 am

On performance, trying something is dirt cheap (even cheaper than checking retcodes IIUC), and the slow part is when an exception actually gets thrown.
 
Duct Tape Dude
Gerbil Elite
Posts: 700
Joined: Thu May 02, 2013 12:37 pm

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 7:30 am

derFunkenstein wrote:
I'm just applying the .NET way of thinking to my Java programs, apparently. :lol:
That's generally an okay thing to do. Java is basically .NET with different boilerplate, a fractured community, frequently broken or insecure releases, a cute nonsensical mascot, and a garbage collector multiple garbage collectors that require more tuning than a middle school orchestra.

synthtel2 wrote:
On performance ...
It's Java, performance is a pipe dream. Not even G1GC can save him now!
 
just brew it!
Gold subscriber
Administrator
Posts: 51540
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 8:00 am

My take: Exceptions generally should be used only in situations which are, well, "exceptional". They should be used to handle conditions which you do not expect to occur routinely during normal execution, but can occur, and need to be handled in a controlled manner when they do.

IMO, using them as part of your normal control flow logic (i.e. where a simple "if/else" construct would work) tends to obfuscate the program logic.

As with all grey areas, reasonable minds can disagree; but I've seen a lot of "spaghetti code" where the convoluted logic was exacerbated by over-use of exceptions: "OK, if something bad happens in here, where the f*ck do I end up?" And yes, well-written code should be structured such that it doesn't matter where the exception eventually gets caught; but you're talking about theory vs. reality.
Nostalgia isn't what it used to be.
 
SecretSquirrel
Minister of Gerbil Affairs
Posts: 2416
Joined: Tue Jan 01, 2002 7:00 pm
Location: North DFW suburb...
Contact:

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 8:23 am

In my view, exceptions are for exceptional events that you cannot control. A try/catch block is a way to trap an event that would otherwise crash or uncleanly terminate a program and allow you cleanup/shutdown in an orderly manner. An empty list, or a node not found in a list is not an exception. It may be an error, depending on the runtime conditions in which it is handled, but there isn't anything inherently fatal.

I once read a comment that said "you should not try/catch any code where you control the entire execution path", or something like that. The general reasoning was that known error conditions should be thought about and handled properly, and exceptions are effectively "throwing up your hands and saying I give up, someone else deal with this".

If your lab partner wrote code like that as an example during a hiring interview with me, it would signal an immediate end to the interview. Having to wrap any interaction with a simple linked list in a try/catch block is simply stupid. Now get off my lawn! :roll:

--SS
 
just brew it!
Gold subscriber
Administrator
Posts: 51540
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 8:53 am

Ahh, hadn't even thought of that angle. "Could cause you to not get a job offer" is a pretty damn good reason to not use exceptions indiscriminately! :lol:

But seriously, when used to implicitly unwind the stack, it's a "prettied up" non-local goto. That alone can be a red flag for a design that hasn't been thought through properly.
Nostalgia isn't what it used to be.
 
chuckula
Gold subscriber
Gerbil Jedi
Posts: 1864
Joined: Wed Jan 23, 2008 9:18 pm
Location: Probably where I don't belong.

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 9:00 am

I tend to agree with JBI. If there are "normal" situations in your program where you expect the null condition then handle it without using exceptions. If, however, "null" only occurs because something has gone wrong outside of the normal expected flow of the program, then throwing an exception is OK.
4770K @ 4.7 GHz; 32GB DDR3-2133; GTX-1080 sold and back to hipster IGP!; 512GB 840 Pro (2x); Fractal Define XL-R2; NZXT Kraken-X60
--Many thanks to the TR Forum for advice in getting it built.
 
derFunkenstein
Gold subscriber
Gerbil God
Topic Author
Posts: 24512
Joined: Fri Feb 21, 2003 9:13 pm
Location: Comin' to you directly from the Mothership

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 9:13 am

chuckula wrote:
I tend to agree with JBI. If there are "normal" situations in your program where you expect the null condition then handle it without using exceptions. If, however, "null" only occurs because something has gone wrong outside of the normal expected flow of the program, then throwing an exception is OK.

But if it's going wrong outside the normal expected flow of the program...hmm.

I guess I don't really understand what you guys are getting at. Getting or using an invalid index is outside the normal expected flow, so I guess an exception there is OK, but that seems like a really low bar to set. I'd much rather just check that the index is valid before proceeding.

Maybe it's because my boss has pounded into me over the last three years or so that try/catch is only for outside input/output (the things I outlined before...user entry, file handling, web services, and I guess I'd add to that database reads/writes). I've been conditioned to believe everything else should be handled decision logic and conditionals.
I do not understand what I do. For what I want to do I do not do, but what I hate I do.
 
chuckula
Gold subscriber
Gerbil Jedi
Posts: 1864
Joined: Wed Jan 23, 2008 9:18 pm
Location: Probably where I don't belong.

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 9:17 am

derFunkenstein wrote:
Maybe it's because my boss has pounded into me over the last three years or so that try/catch is only for outside input/output (the things I outlined before...user entry, file handling, web services, and I guess I'd add to that database reads/writes). I've been conditioned to believe everything else should be handled decision logic and conditionals.


I can see the point your boss is making. When something goes haywire like a file or database record you expect to be available with a particular URI not being there anymore for whatever reason (hardware failure, somebody deleted it, etc.) that's where exceptions are more helpful since those resources are needed for your program to work correctly but might be screwed with by external factors that aren't within the normal flow of your own program.

EDIT: I know this is not a universally accepted practice and of course you can catch exceptions to handle them, but I look at it this way: An exception occurs when something that shouldn't happen does happen and the program really shouldn't continue operation because of the underlying source of the exception. In most of these situations, the value of the exception process is that hopefully there's a pretty detailed call trace dump that helps you identify and fix the underlying source of the error that produced the exception in the first place so it doesn't happen again. It's also usually good to kill a program rather than have it potentially cause data corruption because exceptions were being improperly handled.

However, an error that you expect to happen and can handle properly shouldn't require throwing and catching exceptions to get the job done. But that's not how everybody sees it.
4770K @ 4.7 GHz; 32GB DDR3-2133; GTX-1080 sold and back to hipster IGP!; 512GB 840 Pro (2x); Fractal Define XL-R2; NZXT Kraken-X60
--Many thanks to the TR Forum for advice in getting it built.
 
just brew it!
Gold subscriber
Administrator
Posts: 51540
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 10:50 am

derFunkenstein wrote:
I guess I don't really understand what you guys are getting at. Getting or using an invalid index is outside the normal expected flow, so I guess an exception there is OK, but that seems like a really low bar to set. I'd much rather just check that the index is valid before proceeding.

I would argue that if the code routinely tries to access something at an invalid index, then the code is poorly thought out. In other words, I am agreeing with you -- just check the damn index first.
Nostalgia isn't what it used to be.
 
Waco
Gold subscriber
Minister of Gerbil Affairs
Posts: 2451
Joined: Tue Jan 20, 2009 4:14 pm
Location: Los Alamos, NM

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 11:25 am

I agree with all of the above - exceptions are supposed to be exceptional. Don't use them unless you really did just hit something that is actually unexpected. If I see code that throws exceptions for simple stuff constantly I'm going to be fairly angry at whomever did that.

I'm a C/Fortran guy though, so take my opinions with that grain of salt. :)
Z170A Gaming Pro Carbon | 6700K @ 4.4 | 16 GB | GTX Titan Xm | Seasonic Gold 850 | XSPC RX360 | Heatkiller R3 | D5 + RP-452X2 | Cosmos II | Samsung 4K 40" | 2048 + 240 + LSI 9207-8i (128x8) SSDs
 
derFunkenstein
Gold subscriber
Gerbil God
Topic Author
Posts: 24512
Joined: Fri Feb 21, 2003 9:13 pm
Location: Comin' to you directly from the Mothership

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 11:38 am

just brew it! wrote:
derFunkenstein wrote:
I guess I don't really understand what you guys are getting at. Getting or using an invalid index is outside the normal expected flow, so I guess an exception there is OK, but that seems like a really low bar to set. I'd much rather just check that the index is valid before proceeding.

I would argue that if the code routinely tries to access something at an invalid index, then the code is poorly thought out. In other words, I am agreeing with you -- just check the damn index first.

In the stuff I do at work, it should never happen. More often than not it's a List made from a JSON record, and the user clicks an item and does a thing. That index should still obviously exist. :lol: I'm more likely to run into nulls (where the web service didn't return anything, which is potentially expected behavior) and I just make sure the list isn't null before proceeding.
I do not understand what I do. For what I want to do I do not do, but what I hate I do.
 
chuckula
Gold subscriber
Gerbil Jedi
Posts: 1864
Joined: Wed Jan 23, 2008 9:18 pm
Location: Probably where I don't belong.

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 11:42 am

Waco wrote:
I'm a C/Fortran guy though, so take my opinions with that grain of salt. :)


That just makes you all around exceptional!

I still vaguely recall the indentation rules from my limited time doing Fortran 77 because the first five columns of each line were reserved for punchcard index numbers.
And while I'm old, no I'm not *that* old, and it was laughably obsolete even then.
4770K @ 4.7 GHz; 32GB DDR3-2133; GTX-1080 sold and back to hipster IGP!; 512GB 840 Pro (2x); Fractal Define XL-R2; NZXT Kraken-X60
--Many thanks to the TR Forum for advice in getting it built.
 
just brew it!
Gold subscriber
Administrator
Posts: 51540
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 11:58 am

Waco wrote:
I agree with all of the above - exceptions are supposed to be exceptional. Don't use them unless you really did just hit something that is actually unexpected. If I see code that throws exceptions for simple stuff constantly I'm going to be fairly angry at whomever did that.

Some code I am currently working on cleaning up abuses exceptions extensively. It is considered "normal" for the logs to be littered with Python stack tracebacks. :roll: Makes it really hard to figure out what went wrong when the logs are 99.9% noise and 0.1% signal. :evil:

Oh, and just to make matters even worse, this code abuses threads too.

chuckula wrote:
Waco wrote:
I'm a C/Fortran guy though, so take my opinions with that grain of salt. :)

That just makes you all around exceptional!

I still vaguely recall the indentation rules from my limited time doing Fortran 77 because the first five columns of each line were reserved for punchcard index numbers.
And while I'm old, no I'm not *that* old, and it was laughably obsolete even then.

I'm *that* old. :lol:

I was still in college when they phased out the use of punch cards in the lower-level undergrad CS courses.
Nostalgia isn't what it used to be.
 
DancinJack
Grand Gerbil Poohbah
Posts: 3863
Joined: Sat Nov 25, 2006 3:21 pm
Location: Kansas

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 12:19 pm

Waco wrote:
I agree with all of the above - exceptions are supposed to be exceptional. Don't use them unless you really did just hit something that is actually unexpected. If I see code that throws exceptions for simple stuff constantly I'm going to be fairly angry at whomever did that.

I'm a C/Fortran guy though, so take my opinions with that grain of salt. :)

Add a +1 to this from me. Though I'm not a Fortran guy :)
i7 6700K - Z170 - 16GiB DDR4 - GTX 1080 - 512GB SSD - 256GB SSD - 500GB SSD - 3TB HDD- 27" IPS G-sync - Win10 Pro x64 - Ubuntu/Mint x64 :: 2015 13" rMBP Sierra :: Canon EOS 80D/Sony RX100
 
Waco
Gold subscriber
Minister of Gerbil Affairs
Posts: 2451
Joined: Tue Jan 20, 2009 4:14 pm
Location: Los Alamos, NM

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 1:04 pm

just brew it! wrote:
Some code I am currently working on cleaning up abuses exceptions extensively. It is considered "normal" for the logs to be littered with Python stack tracebacks. :roll: Makes it really hard to figure out what went wrong when the logs are 99.9% noise and 0.1% signal. :evil:

Oh, and just to make matters even worse, this code abuses threads too.

I found someone working on something recently that core dumped consistently. The "developer's" workaround was to have a daemon watch for the process to die and restart it rather than spend 15 seconds (yes, that's all it freakin' took when I grabbed a few cores) in a debugger figuring out why it was seg faulting. :evil:

Said "developer" no longer works with me.
Z170A Gaming Pro Carbon | 6700K @ 4.4 | 16 GB | GTX Titan Xm | Seasonic Gold 850 | XSPC RX360 | Heatkiller R3 | D5 + RP-452X2 | Cosmos II | Samsung 4K 40" | 2048 + 240 + LSI 9207-8i (128x8) SSDs
 
just brew it!
Gold subscriber
Administrator
Posts: 51540
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 1:24 pm

Waco wrote:
just brew it! wrote:
Some code I am currently working on cleaning up abuses exceptions extensively. It is considered "normal" for the logs to be littered with Python stack tracebacks. :roll: Makes it really hard to figure out what went wrong when the logs are 99.9% noise and 0.1% signal. :evil:

Oh, and just to make matters even worse, this code abuses threads too.

I found someone working on something recently that core dumped consistently. The "developer's" workaround was to have a daemon watch for the process to die and restart it rather than spend 15 seconds (yes, that's all it freakin' took when I grabbed a few cores) in a debugger figuring out why it was seg faulting. :evil:

Oh, we had that too. Same deal -- service was unstable, so there's also a watchdog service that periodically pings the service and attempts to restart it if it dies. I think we've found and fixed most of the things that were causing random segfaults and asserts. (Yes, you can get a Python program to segfault... you just have to work at it a little harder than in languages that are "closer to the metal". I posted a thread about this a few weeks ago.)

We *haven't* found the source of all of the memory leaks yet. Yes, if you're particularly clever, you can apparently get a Python program to leak memory too! The Band-aid which the previous developer put in place for this one (which is still in place since we haven't found the root cause yet) is to put the service in a memory cgroup. Leak enough memory, you hit the cgroup limit and the OS's out-of-memory handling mechanism shoots you in the head. Then the watchdog service restarts you.

Also, sometimes asking the service to shut down cleanly doesn't work; it shuts down partway and hangs. Well, the shutdown script waits 5 minutes, and if things haven't shut down by then, it shoots the service in the head.

Anyone detecting a pattern here?

Yes, this is a target-rich environment. I guess on the bright side I have job security. :lol:

Waco wrote:
Said "developer" no longer works with me.

Ditto. Praise the Lord!
Nostalgia isn't what it used to be.
 
chuckula
Gold subscriber
Gerbil Jedi
Posts: 1864
Joined: Wed Jan 23, 2008 9:18 pm
Location: Probably where I don't belong.

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 1:29 pm

just brew it! wrote:
Also, sometimes asking the service to shut down cleanly doesn't work; it shuts down partway and hangs. Well, the shutdown script waits 5 minutes, and if things haven't shut down by then, it shoots the service in the head.

Anyone detecting a pattern here?



You don't happen to call that program the oldyeller-daemon do you?
4770K @ 4.7 GHz; 32GB DDR3-2133; GTX-1080 sold and back to hipster IGP!; 512GB 840 Pro (2x); Fractal Define XL-R2; NZXT Kraken-X60
--Many thanks to the TR Forum for advice in getting it built.
 
Duct Tape Dude
Gerbil Elite
Posts: 700
Joined: Thu May 02, 2013 12:37 pm

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 4:40 pm

just brew it! wrote:
We *haven't* found the source of all of the memory leaks yet. Yes, if you're particularly clever, you can apparently get a Python program to leak memory too!
It's not just Python--no garbage collector shields you from accumulating referenced objects. I made the mistake once of unwittingly having a timed event requeue itself twice every time it fired, eventually getting OOMkilled. I took memory snapshots periodically and compared contents, kept wondering why we had no large or permanent objects taking up lots of space, until I realized what I was doing wrong.

My team lead made a sign out of my conclusion: "Don't do stupid things in Javascript." I keep it handy.
 
just brew it!
Gold subscriber
Administrator
Posts: 51540
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 4:56 pm

Duct Tape Dude wrote:
just brew it! wrote:
We *haven't* found the source of all of the memory leaks yet. Yes, if you're particularly clever, you can apparently get a Python program to leak memory too!

It's not just Python--no garbage collector shields you from accumulating referenced objects. I made the mistake once of unwittingly having a timed event requeue itself twice every time it fired, eventually getting OOMkilled. I took memory snapshots periodically and compared contents, kept wondering why we had no large or permanent objects taking up lots of space, until I realized what I was doing wrong.

We've checked for stuff like that, and it doesn't seem to be the issue. Near as we can tell, there's something funny going on with the way it uses SQLAlchemy. Nobody's had time to do the deep dive to get to the bottom of it, especially considering that ditching SQLAlchemy outright is tentatively on the roadmap now.

Duct Tape Dude wrote:
My team lead made a sign out of my conclusion: "Don't do stupid things in Javascript." I keep it handy.

Our equivalent is "don't hand an inexperienced developer a large project and let him go off in a corner and pound away at it for 2 years". As much as we bitch about the guy's code now (and chuckle at all the profanity in his git commit comments), it's pretty clear that it wasn't really all his fault; he was in way over his head, and situation shouldn't have been allowed to develop the way it did. We're in the middle of what I'd call a "meta-RCA" of the whole dumpster fire now, and procedures are being put in place to prevent a repeat.
Nostalgia isn't what it used to be.
 
Duct Tape Dude
Gerbil Elite
Posts: 700
Joined: Thu May 02, 2013 12:37 pm

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 6:31 pm

just brew it! wrote:
Our equivalent is "don't hand an inexperienced developer a large project and let him go off in a corner and pound away at it for 2 years". As much as we bitch about the guy's code now (and chuckle at all the profanity in his git commit comments), it's pretty clear that it wasn't really all his fault; he was in way over his head, and situation shouldn't have been allowed to develop the way it did. We're in the middle of what I'd call a "meta-RCA" of the whole dumpster fire now, and procedures are being put in place to prevent a repeat.
I think you're referring to Conway's Law.
 
Buub
Maximum Gerbil
Posts: 4742
Joined: Sat Nov 09, 2002 11:59 pm
Location: Seattle, WA
Contact:

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 6:54 pm

Bottom line from a C++ perspective: if you have something to return, return it. If not, return nothing. If you have an exceptional situation, throw an exception. (Don't throw exceptions for normalcy, shouldn't need to be said, but sometimes does.) It shouldn't be much more complex than that. If it is, you may need to review your design.
 
SecretSquirrel
Minister of Gerbil Affairs
Posts: 2416
Joined: Tue Jan 01, 2002 7:00 pm
Location: North DFW suburb...
Contact:

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 8:31 pm

Here is another way to look at it, that lines up with what the "exceptions are exceptional" folks are getting at. If you are throwing an exception in your code, the expectation should be that the execution thread terminates. The purpose here is to log as much state and information as possible and give a good traceback, as well as to (maybe) try and clean up.

If a library you are calling throws an exception, whatever thing that library handles should be "terminated". For example, if you have a database library that throws an exception, it should be expected that you cannot cleanly close the database connection, commit transactions, etc. At that point, you should assume any attempt to access that database will fail, and/or make things worse. The library is signaling that it has encountered an situation that it cannot handle, either literally, or figurative in that the library designer cannot chose the correct recovery path and leaves it to you the application writer.

--SS
 
Ryhadar
Gerbil XP
Posts: 459
Joined: Tue Oct 21, 2008 9:51 pm

Re: Better to throw exceptions or return null?

Thu Mar 01, 2018 10:01 pm

The right answer I think is two fold:
  1. Maintain a consistent convention
  2. Document the behavior for others to understand ahead of time

I'm coming from C# too, as a full stack web application developer, and from my experience try/catch blocks are more common because there are more separate pieces. If it makes you feel any better, even Microsoft can't seem to come to a consensus on this at times. In fact, LINQ's First and FirstOrDefault methods give the developer an option.

Microsoft wrote:
Remarks

The First<TSource>(IEnumerable<TSource>) method throws an exception if source contains no elements. To instead return a default value when the source sequence is empty, use the FirstOrDefault<TSource> method.


For what it's worth, I almost always use .FirstOrDefault() and almost never .First(). So, if I were using your LinkedList library I'd probably prefer your convention, derFunkenstein.
 
just brew it!
Gold subscriber
Administrator
Posts: 51540
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Better to throw exceptions or return null?

Fri Mar 02, 2018 6:36 am

Ryhadar wrote:
The right answer I think is two fold:
  1. Maintain a consistent convention
  2. Document the behavior for others to understand ahead of time

Unfortunately, most development organizations will fail at one or (more likely) both of these.
Nostalgia isn't what it used to be.

Who is online

Users browsing this forum: No registered users and 1 guest