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

211–220 of 242 posts

Re: You’re better off using Exceptions

#211

Post by fauigerzigerk »

oehpr wrote: post #205
fauigerzigerk wrote: post #164

Earlier quoted context omitted.

I don't think this is a real difference. You can make the exact same API design mistakes regardless of which error delivery mechanism you use. The important thing is for the API designer to think about the abstractions, i.e which types of errors should be part of the API and which errors are just implementation details that may change. If the API designer is too lazy to put enough thought into that then the result wi…

There is always an onus on an API designer creating an API to express it well. However I think the difference between good vs bad language (and a good vs bad API come to think of it) is that it makes doing the right thing easy (lazy), and the wrong thing hard. I think about this when I think about GraphQL. I like GraphQL, I really do, but GraphQL's N+1 problem is why I don't recommend it. The easy thing is to hammer…

I agree with the principle, but in this case it seems very easy to do the right thing in either language once you have done the hard work of designing a good API. The same goes for doing the wrong thing.

Re: You’re better off using Exceptions

#212

Post by hota_mazi »

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…

It's a pity they're called exceptions, they should be called errors.

Errors can be of two kinds: recoverable and unrecoverable.

Recoverable should be handled by checked exceptions and unrecoverable errors should be handled by runtime exceptions.

Re: You’re better off using Exceptions

#213

Post by quietbritishjim »

safety-second wrote: post #184
waynecochran wrote: post #153

Earlier quoted context omitted.

Yes... RAII is handy, but it doesn’t save you from checking EOF logic in my example.

You could use a File class that throws on EOF, but that would be a really bad idea for C++ since throw/catch are very expensive.

Exceptions are expensive compared to a simple function call, but I imagine they're cheap compared to operations that read from disk. Certainly one exception per file close is not going to hurt.

Re: You’re better off using Exceptions

#214

Post by dragonwriter »

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…

> For example, if a query is made to an API for a record and that record isn't found, the SDK wrapping that API would raise a "Record not found" exception. What the hell? A record not being found is a normal thing!

There are scenarios where it is and scenarios where it is not, it's fairly common for APIs to present both throwing and non-throwing variants (many languages stdlibs, for instance, provide both mechanisms for associative array lookups), and of course in any language with exception handling you can convert either to the other according to the needs of the consuming process at the point where you interface just by wrapping the finction in one which either throws or swallows the appropriate exceptions, depending on which direction you are converting.

Re: You’re better off using Exceptions

#215

Post by ketzu »

horsawlarway wrote: post #200
ravenstine wrote: post #71

Earlier quoted context omitted.

I don't agree. There is nothing inherently irreconcilable about a record not existing. Anyone who expects a database to always have records and that the absence of a record is an "exception" has a very strange way of thinking. It's like if a car was programmed not to start and to turn on an obnoxious alarm bell because the windshield wiper fluid is empty, and the technicians built in a jumper wire to short that circu…

>There is nothing inherently irreconcilable about a record not existing This just isn't true. It depends on what the record is, and what state you're in (aka: CONTEXT). incredibly clear example: 1. User logs in 2. User record no longer exists 3. Exception That's not a recoverable situation, and the client should see that as an unexpected error.

> There is nothing inherently irreconcilable about a record not existing

> This just isn't true. It depends on what the record is, and what state you're in (aka: CONTEXT).

These two things mean the same thing. It's in the context - > it is not an inherent property.

It's not an inherent property - > it's not always present.

Some conclude therefore it shouldn't be an exception by default.

Re: You’re better off using Exceptions

#216

Post by nemetroid »

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)

> My reaction to 'the test fails because map::at threw an exception': stupid STL!!

> A core dump would be so much easier to analyze..

Uncaught exceptions call terminate(), which by default calls abort(), which generates a core dump. So if you want a core dump, just avoid catching the exception.

Re: You’re better off using Exceptions

#217

Post by z3t4 »

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…

The slow, stupid, and impractical way is to first ask if any records exist, before asking for the records. Remember that computers are dumb, but they are also fast. Asking for the records without first asking if they exist is an optimization. The records might exist when you ask if they exist, but then they might be gone when you ask for the actual records, now that would be an error.

Re: You’re better off using Exceptions

#218

Post by horsawlarway »

ketzu wrote: post #215
horsawlarway wrote: post #200

Earlier quoted context omitted.

>There is nothing inherently irreconcilable about a record not existing This just isn't true. It depends on what the record is, and what state you're in (aka: CONTEXT). incredibly clear example: 1. User logs in 2. User record no longer exists 3. Exception That's not a recoverable situation, and the client should see that as an unexpected error.

> There is nothing inherently irreconcilable about a record not existing > This just isn't true. It depends on what the record is, and what state you're in (aka: CONTEXT). These two things mean the same thing. It's in the context - > it is not an inherent property. It's not an inherent property - > it's not always present. Some conclude therefore it shouldn't be an exception by default.

Ok, fair - I should have included the very next sentence in the quote as well, since OPs argument seems to be that missing records should NEVER cause exception:

>Anyone who expects a database to always have records and that the absence of a record is an "exception" has a very strange way of thinking.

But pedantics aside, my point stands. There are absolutely contexts and code paths where a missing record is basically unrecoverable. Why bother returning an error to the local calling context when you know that code doesn't make sense anymore and can't recover? A jump to a new code path is the right call, and exceptions do that (with a lot of nice trace information about why we ended up on that new code path to boot).

Doesn't mean a missing record should always result in an exception, but it's certainly not a "very strange way of thinking".

Re: You’re better off using Exceptions

#219

Post by chaorace »

paulgb wrote: post #43
unlinked_dll wrote: post #10

> Such criticisms typically revolve around scoping considerations, exceptions-as-control-flow abuse or even the assertion that exceptions are really just a type safe version of goto. Outside of the FP community where people care less about purity - the criticism is more that exceptions are hidden, they're all-or-nothing (either any function can throw, or no functions can, and not all code paths have runtime errors th…

> That just depends on the paradigms of the language you use, anyone can add sugar to make either easier/harder to read. The questionmark operator, in particular, is what sold me on the possibility that this type of programming can be concise and ergonomic. https://doc.rust-lang.org/edition-guide/rust-2018/error-hand...

I've not used Rust before, but this looks a lot like monads! Can I map/flatmap over these or do I have to unpack them later?

If you _can_ operate on those like collections, Rust is a much more fun language than I initially gave it credit for!

Re: You’re better off using Exceptions

#220

Post by baddox »

erik_seaberg wrote: post #204
baddox wrote: post #112

Earlier quoted context omitted.

> It's not a normal thing for code that needs that record that wasn't found. In many popular programming languages, the way to check whether some value has a certain property is with an “if” statement. It would be very odd to replace every code path inside an “if” statement with exception control flow simply because that code path “needs” some condition to be met for it it to execute.

If a user doesn't exist, any code that relies on having a user is broken, and I want a guarantee that code can't be reached. Throwing does that, mapping an Option does that, but "if" doesn't.

That's just a matter of a specific language's syntax, type-checking, or linting. Pattern-matching in OCaml [0] will in most cases warn about non-exhaustive checks. It seems like TypeScript has something similar, although I haven't used it [1].

[0] https://www2.lib.uchicago.edu/keith/ocaml-class/pattern-matc...

[1] https://dev.to/babak/exhaustive-type-checking-with-typescrip...

Post reply on HN