← Back to context

Comment by forrestthewoods

1 day ago

> What if you don't control those call sites?

If I am choosing to change the API contract then someone who wants to use the new API has to update. This is not a big deal.

> If the function doesn't use exceptions for normal error conditions, then no, it's not a new contract

I disrespectfully and emphatically disagree. I do not accept your definition of contract.

> You could do something like (try-catch wrapper)

Let me be clear. Having to add a bunch of random fucking try-catch bullshit around every fucking function call is EXACTLY why I hate exceptions and is EXACTLY what I think is bad software design.

If you think a function should return a value or some unspecified exception whose details are irrelevant then that function could return an option with no information loss, or a result with an Error that is ignored.

> You wouldn't iterate a vector like this, I imagine?

I wouldn’t use at(i) for iteration. The only reason for a function like at(i) to exist is because you want it to be fallible.

> Let me be clear. Having to add a bunch of random fucking try-catch bullshit around every fucking function call is EXACTLY why I hate exceptions and is EXACTLY what I think is bad software design.

The whole point of exceptions is that you don’t need to handle errors at every call site. You can just have one central try-catch block at a place where you have a way to deal with the error, such as report it to the user.

> having to add a bunch of random fucking try-catch bullshit around every function call

Not the person you are replying to, but did you see where he said:

> When exceptions are misused

>If I am choosing to change the API contract then someone who wants to use the new API has to update. This is not a big deal.

Throwing lets you handle the new situation without changing the API at all.

>Let me be clear. Having to add a bunch of random fucking try-catch bullshit around every fucking function call is EXACTLY why I hate exceptions and is EXACTLY what I think is bad software design.

See, that's what happens when you form your opinions on half-digested ideas. Let me be clear. You don't add "a bunch" of try-catch blocks. You don't wrap every call that's capable of failing exceptionally in a try-catch block. That's exactly how you don't use exceptions. The whole point of exceptions is that the compiler will handle the stack unwinding for you so you don't need to worry about it. If you don't want to, or don't know how, or can't handle an exception at a specific point then don't. Let it bubble up for someone else to catch. See the ellipsis in my example? Inside of it you might have a gigantic call tree that performs all sorts of different operations that may all fail in different and unexpected ways. You could write the whole thing and not have a single try-catch besides the one I wrote explicitly. Let me reiterate; this is what you DON'T do:

  try{
    foo();
  }catch (...){
    return Error1;
  }
  try{
    bar();
  }catch (...){
    return Error2;
  }
  try{
    baz();
  }catch (...){
    return Error3;
  }

The only reason you would do something like this is to satisfy a specification such that you have to return different errors, specifically when each of the different calls fails. So... don't specify your functions such that you're required to do this? Just do

  foo();
  bar();
  baz();

or if you really must not throw from the function,

  try{
    foo();
    bar();
    baz();
  }catch (...){
    return SomethingFailed;
  }

TL;DR: Instead of bitching about exceptions, learn how to use them properly.

  • > Throwing lets you handle the new situation without changing the API at all.

    I do not disagree. https://xkcd.com/1172/

    If you add exceptions to a library that didn’t previously use them then I almost definitely have to update my code. The fact that it compiles and runs but will behave in undesirable ways makes it even worse, not better!

    > or if you really must not throw from the function,

    I’m aware.

    But if your library that offers foo adds exceptions now I need to think about it at every single callsite, and probably wrap the function. It’s extremely irritating.

    > learn how to use them properly.

    In my 20+ years of professional C++ development I have a great experience not using exceptions and a strictly negative experience using them.

    Perhaps sometimes I’ll stumble upon a library or codebase where exceptions make the code simpler, easier to understand, and easier to write. But my experience is exceptions make everything strictly worse and that not using exception is a strict win with zero downsides.

    • >The fact that it compiles and runs but will behave in undesirable ways makes it even worse, not better!

      * Exceptions

      * Unstable API

      * Incorrect behavior

      Pick your poison. I know what I prefer.

      >But if your library that offers foo adds exceptions now I need to think about it at every single callsite

      You really don't. Like I said, it's kind of the whole point of exceptions.

      >In my 20+ years of professional C++ development I have a great experience not using exceptions and a strictly negative experience using them.

      Hence my recommendation to learn how to use them. I can replace "exceptions" with anything else (computers, diesel engines, HR people), and there's probably someone who holds that belief. That doesn't make it true.

      And GTFO with that No True Scotsman nonsense. That a tool can be misused doesn't delegitimize the tool. If you saw someone using classes instead of namespaces you wouldn't conclude classes are bad, you'd call that person a knobhead.

      13 replies →

    • > If you add exceptions to a library that didn’t previously use them then I almost definitely have to update my code.

      No, that's the whole point. You let them bubble up to the top of the event loop and you report the error to the user. As a user, anything else leads to shitty software where the programmer tries to outsmart the world around them (and fails, obviously, leading to worse end-user experience than just admitting that you don't and can't have control over everything)

      3 replies →