I'm looking for a way to generate a warning anywhere in my code (top level, class, functions). As I'm typically having a 0 warning policy, this enables me to see where I make a change I need to revert before commit
For example in Java, i could do this:
private int warning_revert_to_false;
boolean DEBUG = true;
and it will generate a warning (according to my settings).
Using jslint/jshint that's easy (mixed tab/space for example), in C/C++ i can use pragma...
Basically I want the code to still compile and run and so far in Dart, I could not find a simple solution and I'm sure there is one that I have missed. Thanks!
Add the following library to your program:
library forced;
import 'package:meta/meta.dart';
class Forced {
#deprecated
static void warning() {
}
}
Wherever you want a forced warning you can simply write:
Forced.warning();
Related
I tried to handle exception like this.
try {
// some functions that likely to throw error
} catch (e) {
print(e);
}
but this print(e) didn't tell me where error come from, it only tell me what error is.
I want to know where error come from and have links that navigate to that line. like this
I also don't want to log on release version, so print is not my anwser.
Can you please give any example on how to do this?
There's a couple of options here depending on whether or not you'll want to be able to control logging output throughout your application or if this is a one-off situation.
Solution 1: make use of asserts
In Dart, assert(...) invocations are only included in debug builds (e.g. processes started via flutter run or dart --enable-asserts foo.dart). You can utilize this fact to conditionally execute code depending on whether or not your program is running in release by doing the following:
assert(() {
print('debug-only logging');
}());
Solution 2: use package:logging
A more general solution is to use package:logging to set up a global Logger instance and then only log through that interface. This package lets you write logs with different verbosities and the level property of Logger can be used to determine which log levels are actually printed. This can be combined with solution #1 to conditionally enable logging throughout the application only while debugging:
void main() {
// Disable logs by default.
myLogger.level = Level.OFF;
assert(() {
// Enable logs in debug mode.
myLogger.level = Level.ALL;
}());
// Your logic here
// ...
}
Is there a way to do the equivalent of #Stepwise's failure behavior for a single feature? We have some integration tests that are set up such that setupSpec() kicks off a Kafka process, and then the actual test checks that each step happened. If step 3 failed, there's no reason to bother checking subsequent steps.
There is no built-in way to do this, but assuming you are using a recent 2.x Spock version and not 1.3 or so, a relatively simple annotation-driven Spock extension can do the trick for you.
package de.scrum_master.stackoverflow.q71414311
import org.spockframework.runtime.extension.ExtensionAnnotation
import java.lang.annotation.ElementType
import java.lang.annotation.Retention
import java.lang.annotation.RetentionPolicy
import java.lang.annotation.Target
#Retention(RetentionPolicy.RUNTIME)
#Target(ElementType.METHOD)
#ExtensionAnnotation(StepwiseIterationsExtension)
#interface StepwiseIterations {}
package de.scrum_master.stackoverflow.q71414311
import org.spockframework.runtime.extension.IAnnotationDrivenExtension
import org.spockframework.runtime.model.FeatureInfo
import org.spockframework.runtime.model.parallel.ExecutionMode
class StepwiseIterationsExtension implements IAnnotationDrivenExtension<StepwiseIterations> {
#Override
void visitFeatureAnnotation(StepwiseIterations annotation, FeatureInfo feature) {
// Disable parallel iteration execution for #StepwiseIterations feature,
// similarly to how #Stepwise disables it for the whole specification
feature.setExecutionMode(ExecutionMode.SAME_THREAD)
// If an error occurs in this feature, skip remaining iterations
feature.getFeatureMethod().addInterceptor({ invocation ->
try {
invocation.proceed()
}
catch (Throwable t) {
invocation.getFeature().skip("skipping subsequent iterations after failure")
throw t
}
})
}
}
Add this to your code base, annotate your iterated test with #StepwiseIterations and run it. I think the result is exactly what you are looking for.
In Spock 1.3, an similar, but more complex extension would also be possible.
I also want to express my special thanks to Leonard Brünings, Spock maintainer and boundless source of knowledge. I had a more complex version of this extension in place, but after discussing with him, it evolved into this tiny, elegant solution we are seeing here.
FYI, there is a pre-existing Spock issue #1008 requesting this feature. I created pull request #1442 which adds this capability to #Stepwise. So hopefully in the future we do not need an extra annotation and extra extension anymore.
What's the best way to open a file in the default application from Vala?
A bit like how xdg-open works.
I found some existing code in another application, but later on I also found this
GLib.AppInfo.launch_default_for_uri method.
A simple example:
var file = File.new_for_path (file_path);
if (file.query_exists ()) {
try {
AppInfo.launch_default_for_uri (file.get_uri (), null);
} catch (Error e) {
warning ("Unable to launch %s", file_path);
}
}
If you're using GTK, then you've also got Gtk.gtk_show_uri_on_window(), which uses the GLib stuff under the hood.
As far as I know there is only one implementation of the relevant freedesktop.org standards.
That is the reference implementation in xdg-utils:
https://www.freedesktop.org/wiki/Software/xdg-utils/
The tools are written in shell script, for example here is the source code for xdg-open:
https://cgit.freedesktop.org/xdg/xdg-utils/tree/scripts/xdg-open.in
So by far the easiest way is to just call the xdg-open script via Process.spawn_async and friends.
If you insist on using a library function you would have to implement a standard conforming library yourself.
Update:
There are quite a few libraries in various languages that implement some of the freedesktop.org standards, for example here is a list on GitHub:
https://github.com/topics/xdg
For example here is a similar tool to xdg-open written in D:
https://github.com/FreeSlave/mimeapps/blob/master/source/mimeapps.d
What I didn't find so far is a Vala / GLib or plain C library that could easily be used from a Vala application.
Update 2:
Actually it turns out there is something for that purpose in GLib (or more precisely in Gio):
https://valadoc.org/gio-2.0/GLib.AppInfo.launch_default_for_uri_async.html
https://developer.gnome.org/gio/stable/GAppInfo.html
So you should be able to use the GLib.AppInfo.launch_default_for_uri_async method.
I'm new to dart, and following the tutorial provided on the Dart for the web page.
It all makes sense - apart from one piece of sytax:
final InjectorFactory injector = self.injector$Injector;
Here's the full code from the tutorial:
import 'main.template.dart' as self;
const useHashLS = false;
#GenerateInjector([
routerProvidersHash,
ClassProvider(Client, useClass: InMemoryDataService),
// Using a real back end?
// Import 'package:http/browser_client.dart' and change the
above to:
// ClassProvider(Client, useClass: BrowserClient),
])
final InjectorFactory injector = self.injector$Injector;
void main() {
runApp(ng.AppComponentNgFactory, createInjector: injector);
}
I'm a confused by the apparent .method$Class syntax. Can anyone explain to me what this means/what it's doing?
It's also underlined in Webstorm with the message The getter 'injector$Injector' isn't defined for the class 'self'. Regardless, it runs fine and works as expected.
Thanks in advance!
$ in an identifier has no special meaning. It's by convention often used for names in generated code.
Angular also uses code generation and the code will only become available after code generation was executed for example by webdev serve or webdev build.
I don't know the current state but the code might still be generated in a directory that is not analyzed by the DartAnalyzler and you might always see the error even wen the app can be run without problems.
Dart is suppose to be pragmatic, intuitive, etc.
I wonder Why top-level main() does not set exitcode if int is returned?
I know, you can set it via dart:io.exitCode= or use dart:io.exit().
The question is why language designers decided to drop such popular convention?
#!/path/to/dart --checked
int main() {
int myExitCode = 5;
return myExitCode;
}
It returns 0 (as described in documentation), but in command-line world it's just silly.
It does not even warn you (compiler checked mode, dartanalyzer). Script just silently return 0. Is there any rationale behind it?
UPDATE:
proposal bug: https://code.google.com/p/dart/issues/detail?id=21639
The main() method in Dart always returns void, even if you specify otherwise. See The main() function As mentioned in the answer from John Evans, you must use the exit function if you want to return a value. This is because the Dart VM runs in both CLI and in a browser. It makes no sense in terms of the browser to provide a return value from main(). Thus the functionality is limited to the dart:io library which will only run in the CLI version of the dart VM.
My understanding for this is that while main() may finish executing, you might have other asynchronous work going on that hasn't completed yet. You can use exit from the dart:io lib to return a exit code immediately.
import 'dart:io';
main(){
exit(42);
}
More info from the API docs about exit: https://api.dartlang.org/apidocs/channels/stable/dartdoc-viewer/dart:io#id_exit
Possible answer would be that returning value from main() will not make sense in browser (as Matt B pointed out, +1), so dart does not let it at all.
But this is incoherent, since getting list of commandline arguments main(List<String> args) does not make sense in a browser environment either, and dart languages supports main(List<String> args).
On the other hand, support for main-return-sets-exitCode feature would tight heart of dart
(how top-level main() is treated) to dart:io which is not available in browsers.
However, I personally don't think it wouldn't be that bad as having such wired and unexpected behavior as shown in the question's code.