|
|
wow!
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Brisingr Aerowing wrote: This guy is LUCKY! Or really very unlucky to be the only person out of 7 billion people to be there at that exact spot at that exact time!
Well, I guess he could've been at worse places.
|
|
|
|
|
Sander Rossel wrote: Or really very unlucky to be the only person out of 7 billion people to be there at that exact spot at that exact time! I admire your pessimism.
You have just been Sharapova'd.
|
|
|
|
|
It's hard work, but as a pessimist you rarely get disappointed
|
|
|
|
|
You think that was a close call, wait until you see this.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Watch One Year of the Earth From a Million Miles Away[^]
Awesome!
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
Dude!
|
|
|
|
|
What a beautiful planet we live on!
Amazing work by NASA.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Can you use style tags in an article?
Didn't know where to ask so I got fire britches on.
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
|
Ahhh thanks for heads up.
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
|
I just used a bottle brush to clean my laptop's power jack, and it started charging the instant I plugged it in. I'm going to let it charge for a while and then turn it on and see what happens. I still think the power brick is bad, though.
A whole pile of dark-colored junk came out of the jack when I cleaned it, so it was very dirty.
EDIT: Power brick is still bad. It stopped charging when I turned it on, and turning it off caused it to start charging again. Still, this will work for now.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
modified 21-Jul-16 15:54pm.
|
|
|
|
|
Just had the same thing with my phone. Would not charge. Went to see a genius and they stuck a tiny screwdriver in and pulled out a piece of lint the size of Texas. Job done
|
|
|
|
|
R. Giskard Reventlov wrote: size of Texas Must be pretty small then...
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
We get a shiny new "?" operator that takes
string result = null;
if (field != null)
{
result = field.Value;
}
and converts this to
string result = field?.Value
So what about the case where we're handling a flaky API
string result = null;
try
{
result = DodgyApi.GetValue();
}
catch
{
result = null;
}
What would you suggest we do for that? What about a headasplode (*) operator
string result = DodgyApi.GetValue*();
where GetValue* will silently swallow the exception thrown by GetValue and return default .
Or am I setting a new standard for lazy, shameful programming here this hot, lazy afternoon?
cheers
Chris Maunder
|
|
|
|
|
Seems like an awful idea to me - I want code that silently swallows exceptions to be a pain to write.
However, you could always add the suggestion to the Roslyn GitHub repo[^] for discussion. It doesn't seem half as mad as some of the other suggestions on there!
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
In this case, though, it's not really silently swallowing the exception. If the headasplode operator guarantees returning null on exceptions, then in using the operator your're explicitly expressing what you'd like to do if an exception occurs.
It's more like exception handling shorthand than exception ignoring.
|
|
|
|
|
But with that operator, you've got to look closely at every method call to see whether or not it ignores exceptions. With the try..catch block, it's obvious what's happening.
Also, how often do you really need to ignore every possible exception? Isn't it more likely that you'd want to ignore specific exception classes, and let unexpected exceptions propagate?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I agree that making things as obvious as possible is a good approach.
How do you feel about the way Java handles this, where exceptions are part of the method signature, i.e. int addSomeNumbers throws Abc { } . And if you call a method that throws an exception, you have to either handle or rethrow (and add the throws clause to your method) if you want your code to compile.
A lot of people seem to hate Java's checked exceptions, but if you're working on a big enough corporate code base, in which case there are probably at least a few lazy or marginally competent developers on the team, I can see the value in checked exceptions.
|
|
|
|
|
I can see the value, if they're done right. The temptation for lazy devs to add throws Exception is probably too high, though.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
using System;
namespace InMemoriamMaunder
{
public enum DodgyResult
{
ResultNull,
ResultNonNull,
ResultError
}
public static class Dodgy
{
public static DodgyResult RunDodgy<T>(ref T param, Func<T, T> dodgyFunc)
{
try
{
param = dodgyFunc(param);
if (param == null)
{
return DodgyResult.ResultNull;
}
else
{
return DodgyResult.ResultOkay;
}
}
catch (Exception)
{
return DodgyResult.ResultError;
}
}
}
} Tests:
private string SomeFuncError(string astring)
{
astring = null;
return astring.ToString();
}
private string SomeFuncNull(string astring)
{
astring = null;
return astring;
}
private string SomeFuncOkay(string astring)
{
astring = astring + astring;
return astring;
}
string astring1 = "hello";
string astring2 = null;
string astring3 = "whatever";
DodgyResult dr1 = Dodgy.RunDodgy<string>(ref astring1, SomeFuncOkay);
DodgyResult dr2 = Dodgy.RunDodgy<string>(ref astring2, SomeFuncNull);
DodgyResult dr3 = Dodgy.RunDodgy<string>(ref astring3, SomeFuncError); Now, Chris, all you have left to do is boil this down to a single operator
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
modified 21-Jul-16 20:11pm.
|
|
|
|
|
How about something like this:
public abstract class DodgyResult<T>
{
public abstract bool Succeeded { get; }
public abstract T Value { get; }
public abstract Exception Error { get; }
public T GetValueOrDefault(T defaultValue = default(T))
{
return Succeeded ? Value : defaultValue;
}
public static DodgyResult<T> Success(T value)
{
return new SuccessResult(value);
}
public static DodgyResult<T> Failure(Exception error)
{
return new ErrorResult(error);
}
public static explicit operator T(DodgyResult<T> result)
{
return result.Value;
}
public static bool operator true(DodgyResult<T> result)
{
return result.Succeeded;
}
public static bool operator false(DodgyResult<T> result)
{
return !result.Succeeded;
}
private sealed class SuccessResult : DodgyResult<T>
{
public SuccessResult(T value)
{
Value = value;
}
public override bool Succeeded => true;
public override T Value { get; }
public override Exception Error => null;
}
private sealed class ErrorResult : DodgyResult<T>
{
public ErrorResult(Exception error)
{
Debug.Assert(error != null);
Error = error;
}
public override bool Succeeded => false;
public override Exception Error { get; }
public override T Value
{
get { throw new InvalidOperationException(Error.Message, Error); }
}
}
}
public static class DodgyResult
{
public static DodgyResult<T> Success<T>(T value)
{
return DodgyResult<T>.Success(value);
}
public static DodgyResult<T> RunDodgy<T>(Func<T> dodgyFunc)
{
try
{
return Success(dodgyFunc());
}
catch (Exception ex)
{
return DodgyResult<T>.Failure(ex);
}
}
public static DodgyResult<TResult> RunDodgy<T, TResult>(Func<T, TResult> dodgyFunc, T arg)
{
try
{
return Success(dodgyFunc(arg));
}
catch (Exception ex)
{
return DodgyResult<TResult>.Failure(ex);
}
}
}
Testing:
var dr1 = DodgyResult.RunDodgy(SomeFuncOkay, "hello");
var dr2 = DodgyResult.RunDodgy(SomeFuncNull, "doctor");
var dr3 = DodgyResult.RunDodgy(SomeFuncError, "name");
SomeOtherMethod(
(string)dr1,
dr2 ? (string)dr2 : null,
dr3.GetValueOrDefault("continue")
);
Now you don't need ref parameters, and you don't need to declare the variable on a separate line.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Excellent. Thanks for this example, Richard !
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|