Why do languages demand catch blocks when they aren't needed?
The compiler 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;
}
The long story
I'm working in an browser like environment where new API's are introduced frequently. Some API's are silently introduced, no documentation but available.
If I want to use a new API I can set a minimum-version flag in my manifest. But if I set a minimum then this excludes anyone before this version.
I've received emails from users who have various reasons they are unable to upgrade; some are using previous versions simply because they haven't updated and others because of office politics.
I've known businesses who the last time I've checked are still using IE6. A few times I've seen system requirements increased that excludes previous generation hardware.
I could have found when an API was introduced and check against a version number or I could try to include the class so later I could check a supports flag or check if the class is not null.
Since setting a minimum version would exclude a segment of the audience this way I could support the users who have not updated while still providing users who have updated access to the features using newer APIs.
Approach 1:
const system = require("system");
try {
const foo = require("foo");
}
function performSomeAction() {
if (supportsFoo) {
foo.bar();
}
}
Approach 2:
const system = require("system");
var supportsFoo = false;
try {
const foo = require("foo");
supportsFoo = true;
}
function start() {
if (foo) {
// do something
}
}
In my cases I can't see a catch block being necessary.
Semantics:
For my specific case:
Try to import a class using require() and
set a constant or variable to that class / api
If an error is thrown skip any other code in the try block and continue
If no error the constant or variable will not be null
In the constructor check for not-null and enable features for use
Per a comment below here is test code in JS environment:
var x = function() {
try {
console.log("hello")
throw new Error();
console.log("world");
}
// catch(e) {}
console.log("After try");
}
// VM373:6 Uncaught SyntaxError: Missing catch or finally after try
ANOTHER USE CASE (5 days later):
FWIW in CSS there is the idea of a progressive enhancement
.
Because of the way CSS styles are defined, styles can be defined multiple times and styles of the same name that are added last overwrite values set before it.
So you can have this list of styles like so:
body {
color: red;
color: blue;
}
The color will be blue because it is defined last. That's perfectly valid in CSS. It's not right or wrong it's valid.
So this comes in handy when you want to support progressive features without breaking support for earlier browsers:
.slideshow {
display: flex;
display: grid;
}
In the style declaration above the browser will use a grid
display if it is supported and if not it will use flex
display. There is no error thrown for using an incorrect value.
That's the same as:
var element = document.getElementById("label");
element.style.setPropertyValue("flex");
try {
// if the style is not supported the browser retains the value flex
element.style.setPropertyValue("display", "grid");
} catch(e){ /* no catch is needed */ }
You could also write the CSS as:
.slideshow {
display: grid;
}
@supports (display: grid) {
.slideshow {
display: grid;
}
}
The code for that would be:
var element = document.getElementById("label");
element.style.setPropertyValue("display", "flex");
if (CSS.supports("('display:grid')")) {
element.style.setPropertyValue("display", "grid");
}
In both cases you are defining a variable, attempting to set test / set it to a new value that it may not support.
The first approach is recommended for greatest backwards compatibility:
.slideshow {
display:flex;
display:grid;
}
Granted, when setting styles that are not compatible the browser will retain the previous valid values. I'm banking on this knowledge or this information to determine that a catch block is not necessary. This isn't my use case btw. My use case is in the "long story" section.
catch
together withtry
. In fact, you can't usecatch
together withtry
. But that is because in Ruby,try
andcatch
have nothing to do with each other, and neither of the two has anything to do with exceptions.