Mfcttrf

Is there any language that let's you use a try block without a catch block?

The complier or parser complains with this code:

try 
 const utils = require("applicationutils");

But it is ok with this code:

try 
 const utils = require("applicationutils");
 catch(e) 

I don't need the catch block.

I'm using JavaScript if it matters.

Update Example Code:

// setting defaults ahead of try - no need for a catch block
var setting = 10;
var myRegEx = "/123/g";
var supportsRegEx2 = false;

try 
 const utils = require("applicationutils");
 setting = 20;
 myRegEx = "/123/gm";
 supportsRegEx2 = true;

Many languages permit: try ... finally ... or some variant. Take C# as an example. There are plenty of others.

But there is no point in a try ... . It has no meaning without an associated:

• catch(...) ...


• finally ...


• 
  catch(...) ... finally ... .


• 
  catch(...) ... catch(...) ... ... catch(...) ... .

The use case you are highlighting is actually very bad code.

If you are expecting an error, and you do nothing about it, your design is fundamentally flawed.

You could say that this syntax is working as expected. Because it is irritating you enough to look for a solution.

The solution is to either get rid of the try altogether, or figure out how to handle the error.

I don't need the catch block.

But you do need to catch. The behavior of your code with a catch block is to catch any exception, and then forget that it happened. So any exception that tries to pass through will stop, and your code will basically pretend that the try block executed successfully.

So you want a naked try block to act like it catches an exception and ignores it. Here's the thing: a default case is meant to be a common case, one that is useful by many users and not error prone. if doesn't typically require an else because there are many cases where you have nothing to do.

I know nothing about why you want to drop exceptions on the floor and pretend they didn't happen. I'm willing to accept that you have some good justification for doing so. But the fact is, in the general case, it's not a good idea. Most programmers don't want to do it, and there are good arguments to say that it is generally unwise to do this sort of thing.

A good language will let you do something unwise. But a good language will not let you do something unwise by accident. Since the behavior you want is generally unwise, languages tend to make you explicitly request it.

What would that mean?

I would expect:

try 
 const utils = require("applicationutils");

To mean the same thing as:

const utils = require("applicationutils");

try/catch/finally is a well understood pattern, used in a lot of different languages. Exceptions by their very nature imply that there is a recovery handler somewhere else.

It sounds like what you are looking for is VB’s On Error Resume Next, which catches and ignores errors on a line by line basis. Today this is generally considered a bad practice, because it means that there is no actual error handling going on — flow continues as if the previous line had succeeded, which can lead to escalating the level of garbage/damage that is done by bad input, instead of halting or eliminating just the bad input.

The try/catch pattern is useful, because it can segment your algorithm into parts where you can fail but recover, and parts where there is no recovery after failure. And in the event that there is no recovery after failure, it is that part that cannot continue not the rest of the application.

If you have a need for this in js, you could get the same effect, by creating a function that takes a function as it’s argument, wraps it in a executes it inside a try catch block where it just sets an error object. You could then use lambda expressions for any line you would like to resume next on.

var err = 
var ex = function(action)
 try 
 action()
 
 catch (e) 
 err=e
 
 
 var i =5
 ex(t=> alert(i.foo()))
 console.log(i)
 console.log(err.message)

Although it won’t work with lines that declare and initialize variables.