[Proposal] envOrFail() and configOrFail()

[AlexDanault]

Wondering if this is a feature you guys would use. I'm ready to code it and the tests that goes with it.

I already have (and rely on) those functions (tough they aren't very clean at the moment) in my projects, because there are some env() and config() calls which do not have a default value and should never be undefined.

The problem with env() and config() as they are is that they return null when the key does not exist. That's alright for some cases, but there are some settings which should never be undefined, otherwise the application stability is at stake.

Used at the proper places, envOrFail() and configOrFail() would at least cut down debuging time (because a typo in a env/config file or env/config call would show up right away) and at best prevent live applications from going berserk because an env/config was forgotten/typoed during deployment (at the hell of trying to debug why something is misbehaving in production).

The functions would behave like firstOrFail(), it'd simply throw an exception if the key is not defined. I think there's a problem with the envOrFail() because it returns null when the value is not defined AND when it is defined to "null" or "(null)". I'd suggest passing "(undefined)" as a default value to the underlying env() call to catch a real undefined value -vs- a value defined as null.

[Garbee]

See #250 for previous discussion along the same lines of this topic.

[AlexDanault]

@Garbee Interesting. I see the original suggestion kind of hit a wall because a (null) config valus is something legitimate in a lot of cases. Which is why I'm suggesting to add the *OrFail variant so that the dev uses the one according to his use case.

[Garbee]

The discussions should still be consolidated to avoid fracturing.

[AlexDanault]

Alright, sorry, let's continue this in #250 .