Is there a language that let's you use a try block without a catch block?Avoiding new operator in JavaScript — the better waySynchronous vs. asynchronous for publish subscribe communication between JavaScript objectsAdvantages of using pure JavaScript over JQueryClient side authentication through signatures instead of passwordsText conversion - Javascript before saving to db, or php when retrieving?Unit Testing a stateful framework such as Phaser?Using a try/catch to deal with deep object drill downs that will often failIs there a way to use html5 custom elements without javascript?An options parameter vs chained functions for object initialization?Difference in use-cases for just using '.catch' v.s using 'Throw Error…' with '.catch'

multicol package causes underfull hbox

Why is the S-duct intake on the Tu-154 uniquely oblong?

Windows reverting changes made by Linux to FAT32 partion

on the truth quest vs in the quest for truth

Will this series of events work to drown the Tarrasque?

How come Arya Stark wasn't hurt by this in Game of Thrones Season 8 Episode 5?

How to pipe results multiple results into a command?

How to customize the pie chart background in PowerPoint?

Failing students when it might cause them economic ruin

Can an airline pilot be prosecuted for killing an unruly passenger who could not be physically restrained?

Is it possible to determine from only a photo of a cityscape whether it was taken close with wide angle or from a distance with zoom?

Error when running ((x++)) as root

What do you call bracelets you wear around the legs?

Shortest amud or daf in Shas?

How do you cope with rejection?

Alternative classical explanation of the Stern-Gerlach Experiment?

Why didn't Daenerys' advisers suggest assassinating Cersei?

Can a generation ship withstand its own oxygen and daily wear for many thousands of years?

Have the writers and actors of GOT responded to its poor reception?

What technology would Dwarves need to forge titanium?

Lock out of Oracle based on Windows username

Save my secrets!

Physically unpleasant work environment

Can I get the output of a command line program with TeX (using e.g. read18)?



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


Avoiding new operator in JavaScript — the better waySynchronous vs. asynchronous for publish subscribe communication between JavaScript objectsAdvantages of using pure JavaScript over JQueryClient side authentication through signatures instead of passwordsText conversion - Javascript before saving to db, or php when retrieving?Unit Testing a stateful framework such as Phaser?Using a try/catch to deal with deep object drill downs that will often failIs there a way to use html5 custom elements without javascript?An options parameter vs chained functions for object initialization?Difference in use-cases for just using '.catch' v.s using 'Throw Error…' with '.catch'






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








1















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;










share|improve this question






























    1















    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;










    share|improve this question


























      1












      1








      1








      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;










      share|improve this question
















      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;







      javascript try catch






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 2 hours ago







      1.21 gigawatts

















      asked 3 hours ago









      1.21 gigawatts1.21 gigawatts

      549414




      549414




















          3 Answers
          3






          active

          oldest

          votes


















          3














          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.






          share|improve this answer























          • "There is no point to a try ". Hmm... "There's never a use case for it and so it's bad code?" You don't know enough about the situation to know that. Should every if statement have an else statement? The compiler throws errors when you encounter a class you want to import that doesn't exist but you have to import it to use it. I'll add more code.

            – 1.21 gigawatts
            2 hours ago







          • 1





            try finally won't suppress the exception though, it'll get raised in the caller. It seems the OP wants to suppress all exceptions.

            – whatsisname
            2 hours ago






          • 2





            @1.21gigawatts: Exactly what behavior do you want, then? There are only two things that I could imagine happening in this case. The exception gets caught, consumed and dropped; or the exception passes through your code and out into the caller like normal.

            – Nicol Bolas
            2 hours ago


















          3















          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.






          share|improve this answer

























          • FWIW, if does require an else in Haskell since it's not possible to "do nothing".

            – immibis
            15 mins ago


















          1














          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.






          share|improve this answer

























            Your Answer








            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "131"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader:
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            ,
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













            draft saved

            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f391999%2fis-there-a-language-that-lets-you-use-a-try-block-without-a-catch-block%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown

























            3 Answers
            3






            active

            oldest

            votes








            3 Answers
            3






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            3














            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.






            share|improve this answer























            • "There is no point to a try ". Hmm... "There's never a use case for it and so it's bad code?" You don't know enough about the situation to know that. Should every if statement have an else statement? The compiler throws errors when you encounter a class you want to import that doesn't exist but you have to import it to use it. I'll add more code.

              – 1.21 gigawatts
              2 hours ago







            • 1





              try finally won't suppress the exception though, it'll get raised in the caller. It seems the OP wants to suppress all exceptions.

              – whatsisname
              2 hours ago






            • 2





              @1.21gigawatts: Exactly what behavior do you want, then? There are only two things that I could imagine happening in this case. The exception gets caught, consumed and dropped; or the exception passes through your code and out into the caller like normal.

              – Nicol Bolas
              2 hours ago















            3














            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.






            share|improve this answer























            • "There is no point to a try ". Hmm... "There's never a use case for it and so it's bad code?" You don't know enough about the situation to know that. Should every if statement have an else statement? The compiler throws errors when you encounter a class you want to import that doesn't exist but you have to import it to use it. I'll add more code.

              – 1.21 gigawatts
              2 hours ago







            • 1





              try finally won't suppress the exception though, it'll get raised in the caller. It seems the OP wants to suppress all exceptions.

              – whatsisname
              2 hours ago






            • 2





              @1.21gigawatts: Exactly what behavior do you want, then? There are only two things that I could imagine happening in this case. The exception gets caught, consumed and dropped; or the exception passes through your code and out into the caller like normal.

              – Nicol Bolas
              2 hours ago













            3












            3








            3







            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.






            share|improve this answer













            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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered 3 hours ago









            Kain0_0Kain0_0

            4,892420




            4,892420












            • "There is no point to a try ". Hmm... "There's never a use case for it and so it's bad code?" You don't know enough about the situation to know that. Should every if statement have an else statement? The compiler throws errors when you encounter a class you want to import that doesn't exist but you have to import it to use it. I'll add more code.

              – 1.21 gigawatts
              2 hours ago







            • 1





              try finally won't suppress the exception though, it'll get raised in the caller. It seems the OP wants to suppress all exceptions.

              – whatsisname
              2 hours ago






            • 2





              @1.21gigawatts: Exactly what behavior do you want, then? There are only two things that I could imagine happening in this case. The exception gets caught, consumed and dropped; or the exception passes through your code and out into the caller like normal.

              – Nicol Bolas
              2 hours ago

















            • "There is no point to a try ". Hmm... "There's never a use case for it and so it's bad code?" You don't know enough about the situation to know that. Should every if statement have an else statement? The compiler throws errors when you encounter a class you want to import that doesn't exist but you have to import it to use it. I'll add more code.

              – 1.21 gigawatts
              2 hours ago







            • 1





              try finally won't suppress the exception though, it'll get raised in the caller. It seems the OP wants to suppress all exceptions.

              – whatsisname
              2 hours ago






            • 2





              @1.21gigawatts: Exactly what behavior do you want, then? There are only two things that I could imagine happening in this case. The exception gets caught, consumed and dropped; or the exception passes through your code and out into the caller like normal.

              – Nicol Bolas
              2 hours ago
















            "There is no point to a try ". Hmm... "There's never a use case for it and so it's bad code?" You don't know enough about the situation to know that. Should every if statement have an else statement? The compiler throws errors when you encounter a class you want to import that doesn't exist but you have to import it to use it. I'll add more code.

            – 1.21 gigawatts
            2 hours ago






            "There is no point to a try ". Hmm... "There's never a use case for it and so it's bad code?" You don't know enough about the situation to know that. Should every if statement have an else statement? The compiler throws errors when you encounter a class you want to import that doesn't exist but you have to import it to use it. I'll add more code.

            – 1.21 gigawatts
            2 hours ago





            1




            1





            try finally won't suppress the exception though, it'll get raised in the caller. It seems the OP wants to suppress all exceptions.

            – whatsisname
            2 hours ago





            try finally won't suppress the exception though, it'll get raised in the caller. It seems the OP wants to suppress all exceptions.

            – whatsisname
            2 hours ago




            2




            2





            @1.21gigawatts: Exactly what behavior do you want, then? There are only two things that I could imagine happening in this case. The exception gets caught, consumed and dropped; or the exception passes through your code and out into the caller like normal.

            – Nicol Bolas
            2 hours ago





            @1.21gigawatts: Exactly what behavior do you want, then? There are only two things that I could imagine happening in this case. The exception gets caught, consumed and dropped; or the exception passes through your code and out into the caller like normal.

            – Nicol Bolas
            2 hours ago













            3















            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.






            share|improve this answer

























            • FWIW, if does require an else in Haskell since it's not possible to "do nothing".

              – immibis
              15 mins ago















            3















            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.






            share|improve this answer

























            • FWIW, if does require an else in Haskell since it's not possible to "do nothing".

              – immibis
              15 mins ago













            3












            3








            3








            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.






            share|improve this answer
















            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.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited 14 mins ago

























            answered 2 hours ago









            Nicol BolasNicol Bolas

            9,89042738




            9,89042738












            • FWIW, if does require an else in Haskell since it's not possible to "do nothing".

              – immibis
              15 mins ago

















            • FWIW, if does require an else in Haskell since it's not possible to "do nothing".

              – immibis
              15 mins ago
















            FWIW, if does require an else in Haskell since it's not possible to "do nothing".

            – immibis
            15 mins ago





            FWIW, if does require an else in Haskell since it's not possible to "do nothing".

            – immibis
            15 mins ago











            1














            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.






            share|improve this answer





























              1














              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.






              share|improve this answer



























                1












                1








                1







                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.






                share|improve this answer















                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.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited 34 mins ago

























                answered 1 hour ago









                jmorenojmoreno

                8,96512244




                8,96512244



























                    draft saved

                    draft discarded
















































                    Thanks for contributing an answer to Software Engineering Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid


                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.

                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f391999%2fis-there-a-language-that-lets-you-use-a-try-block-without-a-catch-block%23new-answer', 'question_page');

                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Log på Navigationsmenu

                    Wonderful Copenhagen (sang) Eksterne henvisninger | NavigationsmenurSide på frankloesser.comWonderful Copenhagen

                    Detroit Tigers Spis treści Historia | Skład zespołu | Sukcesy | Członkowie Baseball Hall of Fame | Zastrzeżone numery | Przypisy | Menu nawigacyjneEncyclopedia of Detroit - Detroit TigersTigers Stadium, Detroit, MITigers Timeline 1900sDetroit Tigers Team History & EncyclopediaTigers Timeline 1910s1935 World Series1945 World Series1945 World Series1984 World SeriesComerica Park, Detroit, MI2006 World Series2012 World SeriesDetroit Tigers 40-Man RosterDetroit Tigers Coaching StaffTigers Hall of FamersTigers Retired Numberse