Hacker News Reader

Comment by baq | Hacker News Reader

The biggest expressivity pain point in practice for me is try/catch not being an expression, so I can’t do

   const c = try { … }

View on HN

Yes! This just drives me crazy:

   string something = null;
   try {
      something = mayThrow();
   } catch (SomeException ex) {
      log.Info(ex);
   } catch (Exception ex) {
      log.Fatal(ex);
      throw;
   }
   if (something != null) {
      ...
   }

Would be actually nice if it had F#'s try...with https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... and would allow us something like:

   var something = try {
     mayThrow()
   } with (SomeException ex) {
      log.Info(ex);
   } with (Exception ex) {
      log.Fatal(ex);
      throw;
   }

Or some way to do pattern matching on exceptions for switch expression.

   var something = mayThrow() switch {
     (SomeException ex) => {
       log.Info(ex);
       return null;
     }
     (Exception ex) => {
       log.Fatal(ex);
       throw;
     }
     var passThru => passThru
   }

   var something = (() => {
     try {
       return mayThrow()
     } catch(SomeException ex) {
       log.Info(ex);
       return null;
     } catch(Exception ex) {
       log.Fatal(ex);
       throw;
     }
   })();

Close enough?

not really; can't immediately return from the lambda caller without throwing, always have to either try/catch anyway or if/else the return value of the lambda. (also, it's rather ugly to read and inconvenient to write.)

Another idea, introduce ??? that would invoke on exception :)

   var something = (mayThrow()
      ??? (SomeException ex) => { log.Info(ex); return null} )
      ??? (Exception ex) => { log.Fatal(ex); throw; };

Or maybe just start using Results as return type and get ValueOrDefault :) But when it comes to handling exceptions, I think it explodes there with ifs and processing IENumerables: https://github.com/altmann/FluentResults

But then again, simpler Results wrapper may be used perhaps. But it is a different way of coding and takes some mental shift on how to think about errors and distinguish between error results and true exceptions.

Oh, csharplang already had discussion on the matters about try/catch single statements: https://github.com/dotnet/csharplang/issues/786

> can't immediately return from the lambda caller without throwing

You want to immediately return in the middle of something that was supposed to simulate just evaluating an expression?

You can't immediately return in the middle of 2+2 as well because return is a statement and can't be a part of expression.

I never ever use try/catch in my code. The only time its really necessary is to wrap JSON.parse on use of untrusted input. For everything else it just feels sloppy as through there is insufficient logic in place for handling primary conditions versus edge cases. Also, try/catch will never compile in the JIT.

Perhaps the place I use it most is that try/catch is how you deal with rejected promises that you've `await`ed in an `async` function.

For everything with the slightest bit of I/O it is quite practical if you have even the most trivial assumptions about its form.

Sure, you can check for everything. It often is more effective, but not prettier or easier to read and of course you also will miss cases.

This sounds like some hyperbolic framework nonsense. First of all I/O just means access to an API. I am going to presume you mean messages from a network.

In that case a message from a network either sends or fails and in the case of sending try/catch does nothing for you but provide an error object, and you don't need try/catch to capture the error. In the case of receiving a network message the message comes in or it doesn't. If the message does come in and is malformed your application should be mature enough to handle that appropriately to the benefit of the user instead of crapping out some error messaging to the console. You don't need try/catch to do any of this. A simple if condition is more than sufficient.

> check for everything

You should check for everything. You only need to check for one thing and if you check for it you are already at 100% of everything. Did you get what you expected: Yes/No?

Disagree.

Usually you don't need to just know if there is an error or not -- sometimes you need to know what that error is. For example, an I/O error versus your image-is-too-small error -- you need to respond to the user differently. I've seen plenty of web apps that treat I/O errors and user input errors as a generic "an error happened" and that is completely wrong. Proper exception bubbling means none of that code that encounters the errors needs to necessarily know how to handle the error and your app always responds correctly.

That said, I don't use exceptions as much in JS because exception handling in JS is still very nascent. There's no base library of exceptions and telling different exceptions apart is not built-in to the language. In a language with more mature exception handling, it's a breeze.

You made the same mistake as the grandparent by assuming I/O means something more specific than it does. At any rate there isn't a good reason to bubble error objects out of the event handler and secondly even if you did you would have everything you need to fully describe the problem within the error object including the stack trace, event type, error message, and so forth.

Its an equivalent breeze in JavaScript as well unless you are fumbling through abstraction layers (frameworks) that eliminate the information you need.

Not at all. You don't have to describe anything when throwing an error because that's the point of exception inheritance. Second, the whole point of exceptions is to bubble them out of the handler(!) because otherwise you would use return values (like in Go).

Since you are saying that you have to describe the problem within the error object, it sounds like you must be you are parsing error messages and stack traces to figure out what the error is. That's not how exceptions are to be used and I think that's why you are not seeing why you would bubble errors.

In other languages, you don't have to do any of that nonsense because object identity is much stronger, but JavaScript uses prototypical inheritance so you can't really tell if an error is an ImageError or an IOError. Despite this issue, exceptions were added to the JavaScript language without resolving that problem. The reason why you have to worry about frameworks eliminating error information is because that problem wasn't resolved and so frameworks roll their own error handling and there is no standard.

> Also, try/catch will never compile in the JIT

Changing the way you program to fit what a JS compiler does or doesn't do is a fool's errand, IMO. The performance benefits are likely to be minimal, confusion for anyone else who has to touch the codebase is high.

And, JS engine's whims change frequently enough that yesterdays micro-optimisation is today's deopt.

Much better to just write ideomatic code.

That depends on how many changes it requires. If its just a matter of don't do these 3 things and your code suddenly becomes more predictable its like being slapped with a magic wand. Everybody wins. All you have to do to ensure 100% of your code compiles in a JIT is be predictable. Predictable code is, on its face, always less confusing.

> The performance benefits are likely to be minimal

This makes me cry, but not a cry of joy or ecstasy. People guessing about performance is perhaps the most frequent anti-pattern in all programming. Please read the following document, you can skip to the end but it may not make much sense if you do.

https://github.com/prettydiff/wisdom/blob/master/JavaScript_...

When developers make random performance assumptions, defensive assumptions are worse, it immediately identifies a lack of professional maturity. Its like small children playing games that expand their imagination, which is great for small children but less great for developers pretending to be adults.

> People guessing about performance is perhaps the most frequent anti-pattern in all programming

I disagree, premature optimisation is.

Changing your style of programming to suit what todays JIT does but tomorrow’s may not, in anticipation of performance issues you have not yet encountered is a waste of everyone’s time. No doubt it is valuable in extremely performance sensitive code but that is the extreme minority, especially in the JavaScript world.

If I were involved in a project where performance concerns were high enough to require everyone know what the JIT is and is not doing my proposal would be to use a language other than JavaScript. If thinking this makes me a “small child” in your mind I’m fine with that.

What you are advocating, the guessing about performance, is the premature optimization. Don't feel bad, most developers have no idea what that term really means. Here is the original essay where it comes from: http://web.archive.org/web/20130731202547/http://pplab.snu.a...

Premature optimization is the extra effort required to alter work necessary to circumvent guessed optimization pitfalls. In the same breath Knuth advocates always targeting known performance advantages.

> Don't feel bad, most developers have no idea

Some advice I know you’ll ignore: your tone in the comments here is deeply patronising. You know absolutely nothing about me and yet are entirely comfortable dismissing my perspective as wrong simply because yours must be correct. It’s not an interesting or rewarding way to converse, it makes me want to stop talking to you as soon as I can. Which I’ll be doing here. Have a good weekend.

Yes, I work in a language where junior developers and people deeply unaware of the language advocate anti-patterns and bad practice as matters of law, often for personal defensive reasons. Its hard to not feel patronized. You are correct in that I do not know you, but I have been doing this work long enough to see when people hide behind abstractions they don't understand as necessary to mask their level of confidence and then argue from for best practices from that perspective.

My best possible free advise: only advocate to what you practice. If, for example, you have never written an application in JavaScript without a framework, such as Angular, then you are an Angular developer not a JavaScript developer. If you speak to something you have never practiced with a presence of authority people with 10, 15, or 20 years experience will be condescending. That is why imposter syndrome is a thing. Its better to get the unexpected honesty from some irrelevant guy online than get hired into a job and either get it in person or worse compensating for a manager with imposter syndrome.

This is exactly what I’m talking about. You are assuming I am inexperienced and have no idea what I’m talking about because I have a different view to you.

For what it’s worth, I’ve spent years working with the innards of various JS engines, managed deployments of JavaScriptCore inside iOS apps (fun fact: no JIT) and using QuickJS in low resource environments (no JIT there either). There’s an interesting conversation to be had around optimising your code for JIT, given the different environments we’ve both worked in. But your ego won’t allow it to take place. A shame for all concerned but in my years of development I’ve met plenty like you and I’m well aware that I’m not about to change your mind so I’ll just leave it there.

> Also, try/catch will never compile in the JIT.

If this is an actual concern (as in you have measured and try/catch is actually affecting something performance sensitive): you can most likely mitigate the impact by isolating the try/catch bodies in separate functions.

I haven’t verified this in every JIT, but I saw meaningful perf improvement in V8 for real world degenerate cases where the performance did actually matter and make a significant difference. But seriously, as always, measure before optimizing stuff like this! It might matter, but it seldom will for anything more than academic curiosity.

> Also, try/catch will never compile in the JIT

This was only ever true in V8, and hasn't been the case since 2017 with the optimizing compiler switch from Crankshaft to TurboFan.

Take a break before lecturing commenters on "guessing about performance is perhaps the most frequent anti-pattern in all programming" next time :)

> Also, try/catch will never compile in the JIT

That's false. It used to be this way with Crankshaft but since 2017 we have Turbofan which solves this.

With async code, there is

    const c = myAsyncFun()
               .catch(e => …)

That leaves c as Promise which was not the type they were looking for. You'd still have to unwrap the promise and deal with the result or rejection. The easiest way to do that is to use await, and if you are using await you'd be better off using try {} catch {} around the async function than .catch().

What does a try expression like this do? Returns null/undefined on a throw?

I suspect you could do something like:

    const c = attempt(() => ... );

where attempt invokes the lambda, catches any exceptions, and does what you want

> What does a try expression like this do? Returns null/undefined on a throw?

If an exception is caught, the expression evaluates to what the catch block evaluates to. (Similar to having if/else be an expression). Of course if the exception isn't caught then it propagates so the expression doesn't take a value.

Kotlin has this feature (`try` and `if` are expressions not statements), and a good model for return values. https://kotlinlang.org/docs/exceptions.html#exception-classe...

I use iife for stuff like this.

const c = (

    ()=> {
        try: {...}
    }

)()

Zig can though:

  const std = @import("std");

  pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print("Hello, {s}!\n", .{"world"});
  }

that's not using `try` as an expression. can you do `let foo = try <code> (plus some handling for diverging in the other case?)`

It can and you in fact either have to mark that you return that error when you use try, or you have to provide a default value in a catch block:

  fn potentiallyErrorReturningFunc() !u64 {
    ...
  }

  const foo = potentiallyErrorReturningFunc() catch { 0 };

One notable difference to most other languages is it being a value only, basically a product type of return value XOR error. These error values get serialized into a number by the compiler that is unique, and on the type system level you deal with sets of these error values. Quite clever in case of a low-level system, in my opinion.

> const foo = potentiallyErrorReturningFunc() catch { 0 };

Nitpick, but AFAIK this won't work and needs to be rewritten either to:

    const foo = potentiallyErrorReturningFunc() catch 0;

...or to:

    const foo = potentiallyErrorReturningFunc() catch blk: { break :blk 0; }

(I wish there would be a more convenient way to return a value from a scope block, not necessarily with a "dangling expression" like Rust, but maybe at least getting rid of the label somehow)

Yes, 'try' can be used like an expression in Zig which resolves to the unwrapped success-result of an error-union, or in case of an error immediately passes the error-result up to the calling function.

Would you not just move that `try { ... }` block into a separate function or method?

Reply on news.ycombinator.com