Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You’re better off using Exceptions

eiriktsarpalis.wordpress.com

Post reply on HN
Print view View original

231–240 of 242 posts

Re: You’re better off using Exceptions

#231

Post by naikrovek »

ravenstine wrote: post #14

My problem with exceptions isn't so much exceptions themselves but the way they're used. The way I see it, exceptions should only be used for things that are irreconcilable, which most of the time is interpreter errors(e.g. undefined is not a function). In other words, I don't think it's that common that custom exceptions are needed outside of assertions to prevent the developer from doing something stupid. If you ar…

> If I need an exception to be raised for this kind of thing, I'll do it myself.

This is the thing. This is the root of the thing. Let developers decide what's right for themselves. There are too many "me-too" developers writing terrible code according to terrible guidelines and terrible "best practices" (lol) and few people are actually thinking about what they're doing.

I agree with everything in your comment. Every single thing, and I wish more people understood your (our?) point of view.

Re: You’re better off using Exceptions

#232

Post by cjfd »

ravenstine wrote: post #198
cjfd wrote: post #134

Earlier quoted context omitted.

The code example is not convincing at all. Obviously a single if is much cleaner than a single try/catch block but that is not the comparison. The if needs to be replicated N times for every N things that could fail and that are calling each other in a potentially deep call hierarchy. The try/catch block only needs to occur once at a level that is above all of the N things that might fail.

That doesn't always make sense when you're dealing with a generic exception class. What you are assuming is that a try-catch block higher up in the hierarchy can handle a RecordNotFound exception for all its descendants, but that's not necessarily going to be the case. It's basically the inheritance problem in object-oriented programming, but in reverse. This is why I'm in favor if exceptions for non-broken states to…

Yes, the try/catch block is better if the catch block can handle exceptions for all its descendants. As always in programming YMMV and this is sometimes true and sometimes it is not and when it is not it is better not to throw an exception.

I agree that a database API should not itself throw an error if an empty result set is found. It may throw an error if there is an SQL error, though, and really should. When one gets an empty result set where this should not happen, for instance because a row was just inserted and one is in a transaction, the user code could throw an exception instead.

Making exceptions optional is something that I have indeed done in the past because some uses of the code could benefit from exceptions while other uses did not so much.

Re: You’re better off using Exceptions

#233

Post by AstralStorm »

dllthomas wrote: post #144
cjfd wrote: post #134

Earlier quoted context omitted.

The code example is not convincing at all. Obviously a single if is much cleaner than a single try/catch block but that is not the comparison. The if needs to be replicated N times for every N things that could fail and that are calling each other in a potentially deep call hierarchy. The try/catch block only needs to occur once at a level that is above all of the N things that might fail.

In my experience, on the web there are two different kinds of things we might be fetching. Some things are essential to the page we are rendering, and if they are missing we should 404. Some things are ancillary, and if they are missing we should render a stub in their place. E.g., saying that a comment is from "deleted user". Exceptions are a good fit for the former, where we want to unify every failure. They are a…

Why are they a poor choice for the latter?

They have a type, make it say MissingUserException and the special place can handle it in a special way. Ensure it is a subclass of some general exception type you also handle elsewhere and you're good.

Often people throw generic exceptions instead of using the type system.

Re: You’re better off using Exceptions

#234

Post by AstralStorm »

renox wrote: post #209
petters wrote: post #127

Earlier quoted context omitted.

In C++, exceptions are often faster than manual error checking when errors are rare. But C++ does not provide a stack trace.

> But C++ does not provide a stack trace Which makes exception in C++ a very, very bad idea! My reaction to 'the test fails because map::at threw an exception': stupid STL!! A core dump would be so much easier to analyze.. Gdb's 'catch thow' is wonderful (well, it is after I fixed the part of our codebase which use exceptions as a control flow mechanism)

C++ can have a stack trace, there are enough libraries providing this functionality and even compiler extensions. Say, libunwind, though you will have to demangle names. And a debugger will see the stack as it is.

Also works in C.

Re: You’re better off using Exceptions

#235

Post by AstralStorm »

iainmerrick wrote: post #192
earenndil wrote: post #191

Earlier quoted context omitted.

Hence 'when errors are rare'.

I guess we’re violently agreeing? Exceptions are an order of magnitude (or several orders) slower than function calls and returns; but that can still be efficient overall, if only a tiny fraction of calls fail. I’d simply add that most people greatly underestimate how expensive exceptions are, even in C++.

Calling the destructors is identical to ending any scope in C++, including function calls. Where is that extra expense?

Re: You’re better off using Exceptions

#236

Post by AstralStorm »

shadowgovt wrote: post #31
ravenstine wrote: post #14

My problem with exceptions isn't so much exceptions themselves but the way they're used. The way I see it, exceptions should only be used for things that are irreconcilable, which most of the time is interpreter errors(e.g. undefined is not a function). In other words, I don't think it's that common that custom exceptions are needed outside of assertions to prevent the developer from doing something stupid. If you ar…

I find the mindset that exceptions are the right way to handle ordinary scenarios symptomatic of what I call "happy path coding:" assuming that the stars are always perfectly aligned for your program to work, and nothing ever goes wrong, and if it does it's someone else's problem. It's a fine approach for prototyping but we should be highly suspicious of it for code people rely upon to work. As complexity approaches…

On the other hand, do you really want to bubble error results through layers of network stack and parsers, when handling is almost always the same?

Re: You’re better off using Exceptions

#237

Post by iainmerrick »

AstralStorm wrote: post #235
iainmerrick wrote: post #192

Earlier quoted context omitted.

I guess we’re violently agreeing? Exceptions are an order of magnitude (or several orders) slower than function calls and returns; but that can still be efficient overall, if only a tiny fraction of calls fail. I’d simply add that most people greatly underestimate how expensive exceptions are, even in C++.

Calling the destructors is identical to ending any scope in C++, including function calls. Where is that extra expense?

You likely have to parse exception blocks and maybe chase pointers to find the objects to destroy. In the happy path, you can just call the destructors directly.

Re: You’re better off using Exceptions

#238

Post by luord »

As someone who's been writing Go for too long, way too long, I agree.

Handling errors everywhere seems to always become ad-hoc exception handling. Oddly, the apologists call this "syntactic sugar for avoiding repetitive error handling", still can't wrap my head around that one.

Re: You’re better off using Exceptions

#239

Post by dllthomas »

AstralStorm wrote: post #233
dllthomas wrote: post #144

Earlier quoted context omitted.

In my experience, on the web there are two different kinds of things we might be fetching. Some things are essential to the page we are rendering, and if they are missing we should 404. Some things are ancillary, and if they are missing we should render a stub in their place. E.g., saying that a comment is from "deleted user". Exceptions are a good fit for the former, where we want to unify every failure. They are a…

Why are they a poor choice for the latter? They have a type, make it say MissingUserException and the special place can handle it in a special way. Ensure it is a subclass of some general exception type you also handle elsewhere and you're good. Often people throw generic exceptions instead of using the type system.

In the latter case you will often want to pass "data or the fact the data was missing" along to other functions. With a result value (of whatever form) that's trivial. With exceptions, it's certainly plenty doable but it's messy.

Re: You’re better off using Exceptions

#240

Post by dgellow »

pat2man wrote: post #4

When I moved to Rust the constant error wrapping or converting annoyed me. But after using it for a couple of years it turned out to be a huge blessing. Quite often I need to know exactly which error messages will be thrown so that I can do things like internationalization. While exceptions are quite convenient for prototyping for production I’m now firmly in the typed errors camp.

> Quite often I need to know exactly which error messages will be thrown so that I can do things like internationalization.

Internationalization of error message? I didn't know that was a thing!

I'm curious about that, do you have some examples I could check?

Post reply on HN